JPS63208941A - Managing system for updating history of program path - Google Patents

Abstract

PURPOSE:To eliminate the useless loop repetition at the time of the debugging by holding the relationship among four elements, i.e., the branches, the nodal points, a bit of row information and the updating classification of a program path in the form of a data base and operating specifically those four elements to control the replacement history. CONSTITUTION:Each path of a program path is expressed in a branch ai and an initiation nodal point vi and a termination nodal point vi+1. The branch ai corresponds to the single instruction mi of a program based on a function G; while the instruction mi corresponds to the replacement type information xi based on a function J. Then it is shown whether the information ti had no new nor old change, is newly inserted or updated. The nodal points vi and vi+1 are allowed to correspond to the replacement type information xi+1 and xi+2 respectively based on a function H. Then it is shown whether those information xi+1 and xi+2 has no new nor old changes, and newly inserted or updated.

Description

[Detailed Description of the Invention] [Summary] To solve the problem that test information based on program paths cannot be used effectively in program path management due to the inability to grasp the correspondence between program paths before and after the update due to program updates. In order to do this, we decompose the program path into branches and nodes.

Techniques: Relationship between nodes and line numbers 1 By creating and operating a program update history management database that expresses the relationship between line numbers and update types, it is possible to manage the update history of program paths associated with program updates. be disclosed.

[Industrial application field]

The present invention relates to a program path update history management method for managing program path update information associated with program updates.

Even if the program is updated, the correspondence between the program path before and after the update cannot be determined, and test information based on the program path cannot be reused. For this reason.

There is a need for a program path update history management method that grasps the correspondence between program paths before and after they are updated.

[Conventional technology]

Analyzing the program structure and finding the program path.

(i) There is no need to randomly repeat and execute loops during debugging.

(11) Paths that test all routes using the least number of patterns can be known in advance.

It is necessary because of its advantages.

FIG. 8 shows an example of conventional processing when a program is updated. Input the created program ■ into the program path generation mechanism ■ to generate a program path ■.

This program path ■ is input to the test case generation mechanism ■ to generate a test case ■. Then, test information (■) is obtained by test execution (■) based on this test case (■).

However, the program ■ has been updated and the update program ■
′, correspondingly ■′, ■′.

■' must be regenerated, and test information ■ cannot be reused.

[Problem that the invention seeks to solve]

The conventional program path generation mechanism (■) generates a program path (■) when a program is input.

At this time, only the history of the program is managed, but the history of the program path corresponding to the program is not managed, resulting in a problem that test information based on the program path cannot be reused. For this reason, the above [
However, the advantages mentioned at the beginning of the section entitled "Prior Art" could not be enjoyed.

[Means for solving problems]

The present invention solves the above problems and allows program paths to be managed to enjoy the above advantages.

FIG. 1 shows a diagram explaining the principle of the present invention.

Since the program path is a directed graph.

Nodes (set V) Technique (set as set A) It consists of

If a certain technique a (εA) exists as shown in the diagram 1000, the nodes Vi ('EV) and v if (ε
V) is arbitrarily determined as follows. And there is one path (to L Q shown). The relevant path 1010
The technique at (illustrated 1020) and the node v! .

Vi4. (1040 in the figure) and is stored as information, and the instruction m! corresponding to the branch ai! (Illustration 10
30) is retained as information. Here, one node Vi or vt4+ is a start point, a stop point, or a branch point of the program, and each branch ai is a sequence of instructions between each node. Note that F, G, H, and J shown in the figure are functions, and conversion according to the functions is performed by indexing a table or the like.

That is, in case F shown in the figure, one path 1010 is extracted by indexing the table based on a certain technique ai.

The program path is a set of these (al, ■, .

vi+1). Here, ai is the technique, vi is the starting point of the node, and Vi. 1 is the end of the node.

In this way, (technique, start node, end node) can be used as the way to hold program path information in the database, and in the present invention.

I'm trying to take advantage of this.

A certain technique ai is associated with one instruction (of a program) mt based on a function G. And command m! Based on the function J, whether the instruction m1 is (i) unchanged from the old program (it is said to be preserved) when updating from the old program to the new program, or (ii)
whether it is newly inserted or (iii) updated (
Update type information X indicating whether the item has been changed (changed)
It can be associated with

Similarly, the nodes Vi and Via+ are respectively based on the function H, and when the corresponding nodes V and V@41 are updated from the old program to the new program, (i) they are saved in the same way as above. Update type information xo, or X, indicating whether the item exists, (ii) whether it is newly inserted, or (iii) whether it has been updated. 2.

[Effect]

By checking the update type information X.

It can be determined whether a certain instruction mi is saved or not, and update type information Xi4. , Xi. By checking 2, it can be determined whether a certain node Vl or Vl, . Then, technique a, node V i I V i 4
1 are saved together, it can be seen that there was no change when updating from the old program to the new program.

Embodiment C] FIG. 2 is an explanatory diagram illustrating a database used in the present invention. In FIG. 2, 1 is an update history management database.

(a) New line information 111° indicating the line position in the new program (corresponding to instruction di in the new program) (b) Line position in the old program (corresponding to instruction m in the old program) Old line information 112° (c) When updating from the old program to the new program, (i) Is it preserved? , (ii) whether it has been newly inserted, or (iii) whether it has been updated (changed), etc. Update type information 113° (d) Command rd! in the new program. The node v' corresponding to
, the fold node information 114° (6) The node V in the old program corresponding to the node v'i!
Old node information 115゜(f) that indicates the new line, comment information 116゜(g
) Comment information 117° that describes the contents of the old line, etc. are written all at once.

Reference numeral 2 is the old pass database.

(h) Gijuko 1 that instructs the technique ai in the old program
i1 2 1゜(i) Node 1 information 122゜(j
) Node 2 information 123° indicating the terminal node v, +1 (k) Instruction information 1 indicating the instruction mi related to technique ai
24° etc. are described together. Furthermore, numeral 3 is a new path database.

(2) Branch information 131゜(m) indicating technique al in the new program, node 1 information 132゜(m) indicating starting node v',
n) Terminal node V'! , Node 2 information 1 indicating I
33°(0) Technique a/, command information 134° instructing related command A, etc. are collectively described.

Hereinafter, with reference to FIGS. 3(A) and 3(B), a process of checking whether any changes have been made during transition from an old program to a new program will be described.

FIG. 3(A) conceptually shows the process of extracting update history information, and reference numeral 4 represents the process of extracting update history information.

In FIG. 3(A), assuming that the extraction process 4 is given as shown, the node vs + of technique a with respect to the branch ai.
vill and instruction mi in the old path database 2.
You can ask for it in the field. As shown in column ■, technique ai corresponds to instruction m, so update history management database 1
The update type information Xi is obtained from the ■ column. Regarding node Vi, update type information X is also obtained from column ■ of database 1.
Find 501.

Regarding node V 66 H, also see ■ in database 1.
Update type information xt4z is found from the column. Update type information
i, Xi. If l r Xi+2 are each preserved (if there is no change between old and new), the path (ai+ vii
It can be seen that Vi+1) is preserved (unchanged).

FIG. 3(B) is an explanatory diagram for explaining functional relationships, and the functions F, G, H, and J shown in the two diagrams are information ai, m, and v at the left end of the diagram.
Information such as Vi, V i 61, m, Xi, X t**, and X got on the right side of the diagram is indexed under the respective functional relationships from 8, '/i*1, etc. This relationship is shown in FIG. 1 by the same functions F, G, H, and J.

As mentioned above, in two embodiments of the present invention.

Using the update history management database 1 and the old path database 2, determine whether the path (a(l vi 1 vi+1)) has been updated.Among all program paths, the updated path (ai + vl * vi*+
) is the updated program path.

This makes it possible to manage the update history of program paths associated with program updates.

FIG. 4 shows the configuration of an embodiment of the program path update history management system of the present invention. For example, suppose that the old program 11 is as shown in FIG. 5, 101, and the editor 12
The new program 13 updated by
Suppose it is something like 2. Note that the path charts 201 and 202 shown in FIG. 6 represent the old program 101 and the new program 102 in a form such as the path 1010 shown in FIG.

At this time, the obtained new program 13 is retained and the command history 14 is extracted. The command history 14 is obtained by matching the two programs Lot and 102 shown in FIG. 5 in line correspondence, and becomes something like the command history 103 shown in FIG. 7.

In this state, when transitioning from an old program to a new program, the process to find updated locations is as follows.

The database generation mechanism 15 shown in FIG. 4 associates the new program 13 with the command history 14 to obtain the update history management database 1' shown in FIG.

This database 1' corresponds to the database 1 shown in FIG. The database generation mechanism 15 also generates the old path database 2' and the new path database 3' shown in FIG. 7, and generates the database 1 shown in FIG.
Stored within 6. Note that the databases 2' and 3' shown in FIG. 7 correspond to the databases 2 and 3 shown in FIG.

The database operation mechanism 17 shown in FIG. 4 uses each of the databases 1', 2', and 3' shown in FIG.

Decompose the path into nodes and branches and check whether they have been updated. Focusing on technique a in the case shown in FIG.

It can be seen from the database 2' that the 9th node is (rsJ, rlJ) and the instruction is "2". and.

It can be seen from the database 1' that the node rSJ has been saved as shown in FIG.

Therefore, it turns out that the path (a, 3°1) has been updated. Other paths (b, 1.1) and (c, 1.H)
Also check in the same way. If both nodes and branches are preserved.

2 small,, ay I+ IHfi six patterns 2.1 The path excluding the saved path obtained from the top of the screen will be extracted as the program path 18 to be tested. .

〔Effect of the invention〕

As explained above (1) According to the present invention, program path history management can be performed by retaining old and new programs and command history.

Test information based on program paths can be reused in updated programs.

[Brief explanation of the drawing]

Fig. 1 is an explanatory diagram of the principle of the present invention, Fig. 2 is an explanatory diagram explaining the database used in the present invention, and Fig. 3 (A
)(B) is a diagram explaining the processing process in the present invention, No. 4
The figure shows the configuration of an embodiment of the present invention. 5, 6, and 7 are explanatory diagrams for explaining the operation of the configuration shown in FIG. 4, and FIG. 8 shows a conventional processing example. In the figure, 1 is an update history management database, 2 is an old path database, 3 is a new path database, 4 is an update history information extraction process, and 14 is a command history. 15 represents a database generation mechanism, and 17 represents a database operation mechanism.

Claims (1)

[Claims] In program path update history management, each path is cut at a branch point, the starting branch point of the cut path is node 1, the terminal branch point is node 2, and the branch point between the branch points is It is structured so that the root is a branch, each path is expressed as three elements: branch, node 1, and node 2, and the program path is expressed as a set of these paths.The program path branches, nodes, and program The relationship of at least four elements between the line information corresponding to the command and the update type operated through the editor (12) for each line information is maintained as a database (1, 2, 3), and the branches and nodes 1 and 2 are A program path update history management method characterized in that the method is configured to obtain update history of a path by extracting update type information using the above line information as neutral, and obtains an update history of a program path.