JPH04247532A - Test supporting system - Google Patents

Abstract

(57) [Summary] This bulletin contains application data before electronic filing, so abstract data is not recorded.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a program test in a modular programming language, and more particularly to a test support system that creates a database of information on modules and the like related to the test and thereby improves the efficiency of the test.

0002

[Background Art] A program is composed of multiple modules, and if a certain module among them is updated, it is necessary to retest it, but by updating it, it is necessary to understand all the tests that need to be re-executed. is difficult. However, no means are provided to obtain the tests to be rerun, and those testing the program must figure this out themselves. These tasks have traditionally relied on the experience and judgment of program personnel.

[0003] Furthermore, when testing a certain function of a program, not all modules making up the program are required. With conventional methods, it is possible to create an executable file by combining only the modules deemed necessary, but there is no way to determine which modules are required for the test to be executed.

0004

[Problem to be solved by the invention] As mentioned above, conventionally,
Testing when changing program modules relied on the experience and judgment of the person in charge of the program, which caused the following problems. For example, when a certain module is updated and a test is re-executed, the decision on the content of the test is left to the person in charge. At this time, even if the function to be modified is tested, if the module is related to other functions, the user may forget to test these functions. In this way, if you use the functions related to updated modules without properly testing them, you may end up causing bugs in unexpected places, and it will take time to find the cause of the bug.

[0005] Furthermore, since there was no means provided for determining which modules are required for a test to be executed, object codes of unnecessary modules were combined, and when testing a large program, it was difficult to create an executable file. The time required to do so and the size of the executable file were considerable. Furthermore, for example, when developing in a group, modules updated by others may be recombined even if they are not necessary for actual testing. In such a case, if a bug occurs, it becomes impossible to determine whether the problem is caused by something you updated or something someone else updated.

Furthermore, when testing a program composed of a plurality of modules, it is necessary to closely monitor the progress of the test. Therefore,
A technology that can accurately grasp the progress of testing for each module is desired.

[0007] In view of these conventional problems, the present invention
The purpose of this invention is to provide a means by which efficient testing can be performed when a module of a program consisting of a plurality of modules is changed.

[0008]

According to the invention, the above objects are achieved by the means set out in the claims. That is, the invention according to claim 1 is a system for supporting the testing of a program in a modularizable programming language, comprising: a database unit having a test compatible module table that associates a relationship between a test to be executed and a module to be tested; An input means for receiving input of a test execution request or support information request, and executing the test when the above input is a test execution request, and recording the modules involved in the execution of the test in the test compatible module table of the database section. an execution means for updating a module, a search means for extracting a test name from a test compatible module table stored in a database section based on the module name, and an output means for displaying information on test support processing results. This is a test support system with

[0009] The invention of claim 2 provides executable information in which each module of a program to be tested is associated with creation information of an executable file of the module, updates the module, and tests the module. a search means for searching and extracting modules required by a program to be combined with a test program from a test compatible module table stored in a database section based on the test name, and execution based on the modules extracted by the above means. 2. The test support system according to claim 1, further comprising processing means for creating an executable file based on information on the executable file creation information.

[0010] The invention of claim 3 provides a module test status table in the database section that associates the relationship between called modules that are called from a test module and are tested in conjunction with each other, and also provides a module test status table that associates the relationship between called modules that are called from a test module and are tested in conjunction with each other. An execution means that records the execution results of the called module called by the calling module and tested in conjunction with the module test status table in the database section, and an execution means that records the execution results of the called module that is called by the calling module and is tested in conjunction with the called module. a search means for extracting a corresponding table from the module test status table stored in the database section; and a search means for extracting a corresponding table from the module test status table stored in the database section; 2. The test support system according to claim 1, further comprising processing means for creating a test progress status expressed as a ratio and a list of untested modules.

[0011]

[Operation] FIG. 1 shows a block diagram illustrating the principle of the present invention. As shown in the figure, the system according to the present invention includes an input section 1 that receives input and analyzes it, and an execution section that executes the test when the user's request is to execute the test and stores the necessary information in the database section 6. unit 2, a search unit 3 that searches the database when the user's request requires information in the database, a processing unit 4 that processes the searched information, and an output unit 5 that notifies the user of the results. It consists of FIG. 2 shows the structure of the test compatible module table 6a, module test status table 6b, and executable file creation information 6c stored in the database section 6.

[0012] In the invention of claim 1, in the execution unit 2a,
When executing a test of a program having a modular structure, a test execution instruction is inputted from the input unit 1. At the time of execution, the execution unit 2a extracts the test name for testing the program (the name given to the test execution unit when the test is divided into patterns, etc.) and the module name to be executed in the test, and extracts the program name. Using this as a key, the test name and module are recorded and stored in the corresponding table of the test compatible module table 6a (FIG. 2(a)) of the database section 6.

[0013] Furthermore, when the contents of a certain module are changed and updated, if you want to search for the test name to be tested again, input the program name and module name from the input section 1, and the search section 3a will input the program name. As a key, the test compatible module table 6a (FIG. 2(a)) in the database section 6 is searched and the corresponding table is extracted. A list of test names for the module specified by input is extracted from the table and displayed on the output section 5.

[0014] In the invention of claim 2, when the contents of a certain module are changed and updated, the modules to be combined necessary for testing the program are recognized and an executable file is created. In order to search for the module required for creation, a program name and a test name are input from the input section 1, and the search section 3b searches the test corresponding module table 6a (FIG. 2(a)) in the database section 6 using the program name as a key. Search the table and extract from that table a list of modules required for execution with the test name specified in the input. Based on the list of modules extracted by the search unit 3b, the processing unit 4a selects a corresponding module from information previously held and recorded by the user in the executable file creation information 6c (FIG. 2(c)) of the database unit 6. Combine and edit object files to create an executable file. If an object file has not been created, compile the source file based on the information in executable file creation information 6c (Figure 2(c)) to create an object file, and combine and edit the object file using the above procedure. Create an executable file.

[0015] In the invention of claim 3, in the execution unit 2b,
When executing a test of a program having a modular structure, a test execution instruction is inputted from the input unit 1. During execution, the execution unit 2b extracts the executed modules among the related modules to be tested among the called modules that are called by the calling module and tests in conjunction with each other, and records the module test status in the database unit 6 using the program name as a key. The called module for each calling module is recorded and stored in the corresponding table of Table 6b (FIG. 2(b)). Note that the module test status table 6b records and stores in advance all the called modules to be tested in conjunction with the calling module to be tested by the user.

[0016] When requesting to grasp the progress of testing and to create a list of untested modules, input the name of the program for which the above is requested from the input section 1, and the search section 3c uses the program name as a key. Database section 6
The corresponding table is extracted from the module test status table 6b (FIG. 2(b)). The processing unit 4b divides the tested module (indicated by a black circle in the figure) by the module to be tested from the table extracted above, and calculates the test progress status expressed by the ratio and the untested module (in the figure). (indicated by white circles) is created and displayed on the output unit 5.

[0017]

[Embodiment] FIG. 3 is a configuration diagram showing an embodiment of the present invention.
This embodiment corresponds to the inventions of claims 1 and 2. Note that FIG. 6 is a diagram showing the structure of the database of the embodiment.

In FIG. 3, when a program test is requested from the input section 11, the execution section 12 performs the processing, stores the processing result in the test compatible module table 16a of the database section 16, and outputs the completion of processing. Displayed in section 15. After the program execution unit 12a starts executing the program, the module list acquisition unit 12b involved in the execution
The processing of the information storage unit 12c from to the database is shown in FIG.
This is done according to the flowchart of the module list acquisition information processing. That is, execution of the program is started in process P1. In process P2, using the program name as a key, database section 1
The test compatible module table 16a (FIG. 6(a)) of No. 6 is searched and extracted. Then, in process P3, the table extracted above is searched using the name of the test to be executed as a key. Next, in process P4, a test of the module of the program to be tested is executed. In process P5, the test name, the module name involved, and the executed module are marked (as shown in FIG. 6(a)) and stored in the corresponding test corresponding module table searched in P3. In process P6, it is determined whether the test of the module to be executed is finished, and the process ends after all the tests have been executed.

When a test name related to a module is requested, the corresponding test corresponding module table is searched from the database 16a using the program name as a key in the correspondence table search unit 13a, and the test name related to the specified module is searched. A list is obtained and displayed on the output device by the output unit 15. An example of this case will be explained with reference to FIG. 6(a). The figure takes as an example a program P consisting of six modules: a, b, c, d, e, and f. In program P, three tests, test1, test2, and test3, are currently being performed. The modules involved in the execution of each test are shown in the figure. Here, update module b,
When you ask what should be retested by this, te
st1 and test2 are obtained.

The above is a description of an embodiment corresponding to the invention of claim 1. Next, the explanation corresponding to claim 2 will be described below. In FIG. 3, when the input unit 11 requests the creation of an executable file for testing, the correspondence table search unit 13a searches the database 16a for the corresponding test compatible module table using the program name as a key. Extracts the list of module names that participated in the execution of the test name.

The executable file creation information search unit 13b checks whether information regarding the object of each module is registered in the executable file creation information 16c. If it is registered, the executable file creation unit 14c creates an executable file based on the information. If not, the executable file creation information acquisition unit 14a inquires of the user whether an object file exists, and if it exists, uses that file; if it does not exist, the Information, that is, content corresponding to the executable file creation information in FIG. 6(c) is inquired.

[0022] Based on the information obtained as a result of the inquiry, an executable file is created in the executable file creation section 14c. This information is registered in the database 16c by the executable file creation information registration unit 14b,
Enables reuse. Note that it will be easier to use if a means to update registered information is provided. A message indicating that the creation of the executable file has been completed is displayed on the output unit 15. The processing from the executable file creation information acquisition section 14a to the executable file creation section 14c is performed according to the flowchart of executable file creation shown in FIG.

That is, in step S1, one module of the corresponding test is extracted from the module list (FIG. 6(a) test compatible module table). Processing S2 displays the extracted module name. In process S3, the user is inquired about the existence of the object file of the module extracted in process S2. As a result, if the object file exists, the module name and object information are stored in step S6. If the module does not exist, the user is inquired about the source file name and compilation method of the module in step S4.

The inquiry result is registered in the database in step S5. Then, in step S6, the module name and object information are stored. If the applicable program has multiple modules, in process S7, processes S1 to S6
Do this repeatedly. When all the object file information of the module necessary for creating an executable file has been collected, an executable file of the corresponding program is created in step S8.

In the example shown in FIG. 6A, when a request is made to create an executable file for test1, the object files of modules a, b, and c are combined to create an executable file.

FIG. 7 is a block diagram showing another embodiment of the present invention, and this embodiment corresponds to the invention of claim 3. In this embodiment, prior to testing a program, a list of modules constituting the corresponding program is recorded in advance in the module test status table (FIG. 6(b)) of the database section 16b using existing technology. Then, test execution is input from the input unit 11.

First, the program configuration module list acquisition section 12d extracts the module test status table of the program to be tested from the database section 16b. and,
The program execution unit 12a starts executing a test of the program. The module list acquisition unit 12e records a list of modules involved in the execution in the extracted module test status table. The information storage unit 12f stores the module test status table (FIG. 6(b)) in the database 16b.
Store in.

At this time, the module test status table shows:
The called module called by the calling module that executed the test is marked (like the black circle in FIG. 6(b)). The processing of the information storage section 12f from the program execution section 12a to the database is performed according to the flowchart of the module list information storage processing shown in FIG. That is, processing F1
The execution of the program is started in step F2, and the corresponding table in the module test status table (FIG. 6(b)) is searched from the program name of the corresponding test.

In process F3, a test of the module is executed. If you want to perform a test by calling another module from this module, it is determined in process F4, and the called module is marked in the module test status table (F2 search) in process F5 (black circle mark in Figure 6(b) ). The completion of the test execution of the module of the corresponding program is determined in process F6, and the process is continued until all processes are completed.

The above describes the process from when a test is executed until the executed module is recorded in the database. Next, a description will be given of a process for creating a test implementation rate and a list of untested modules.

In FIG. 7, when the test status is requested from the input unit 11, the module test status table search unit 13c searches the database 16b using the program name specified in the input as a key, and retrieves the module test status table (FIG. 6). (
b) Retrieve the relevant table of). The total number of tested modules and the total number of called modules to be tested are determined from the table, and the calculation unit 14d divides the total number of tested modules by the total number of called modules to be tested to obtain the test implementation rate. It is possible to obtain not only the entire program but also each module.

If the request is to find out untested modules, the module test status table search unit 13c searches the database 16b using the specified program name as a key to obtain the corresponding module test status table. Create a list of untested modules for each module from the table. In the example of FIG. 6B, modules b and e called from module c, module a called from module d, and module c called from module f are obtained as untested modules. Therefore, the test status of the entire program is 5/9.

[0033] Information necessary to realize the above is as follows:
There is a list of modules involved in execution and a list of modules that make up the program. This list of modules involved in execution can be easily realized by extracting from the output of a trace function that debuggers generally have, or by outputting the information to a file when a module is called during execution. Additionally, a list of modules constituting a program can be obtained by analyzing the program, and may also be provided as a tool for a program description language.

[0034]

As explained above, the present invention has the following advantages. That is, according to the invention of claim 1,
Since it is possible to easily understand the test contents to be re-executed when a certain module is updated, there is no need to omit any tests. Further, according to the invention of claim 2, it is possible to create an executable file that combines only the modules necessary for testing, so it is possible to reduce the time required to create an executable file and reduce the size of the executable file. becomes. Additionally, updates made by other people are less likely to be affected, making testing easier. Further, according to the third aspect of the present invention, it is possible to grasp the untested parts for each module, so it is also possible to grasp the progress of testing on the program. As described above, according to the present invention, it is possible to efficiently test a program composed of a plurality of modules.

[Brief explanation of the drawing]

[Figure 1] Block diagram explaining the principle of the present invention

[Figure 2] Diagram showing a database of the principles of the present invention

[Fig. 3] Configuration diagram of one embodiment of the present invention

[Figure 4] Diagram showing the flow of processing for storing module list information

[Figure 5] Diagram showing the flow of processing for creating an executable file

[
Figure 6: Diagram showing the structure of the database of the example

FIG. 7 is a configuration diagram of another embodiment of the present invention.

[Figure 8] Diagram showing the flow of processing for storing module list information

[Explanation of symbols]

1, 11 Input units 2a, 2b, 12 Execution unit 12a Program execution unit 12b, 12e Module list acquisition unit 12c, 12f involved in execution Information storage unit 12 in database
d Program configuration module list acquisition unit 3a~
3c, 13 Search unit 13a Correspondence table search unit 13b Executable file creation information search unit 13c
Module test status table search parts 4a, 4b,
14 Processing unit 14a Executable file creation information acquisition unit 14b
Executable file creation information registration unit 14c
Executable file creation section 14d Calculation section 5, 15 Output section 6, 16 Database section

Claims (3)

[Claims] Claim 1: A system for supporting testing of programs in modular programming languages, comprising:
a database unit (6) having a test compatible module table (6a) that associates the relationship between the test to be executed and the module to be tested; an input means (1) for receiving an input of a test execution request or a support information request; When the input is a test execution request, the test is executed and the modules involved in the execution of the test are stored in the database section (6).
Execution means (2a) records the test name in the test compatible module table (6a) stored in the database part (6) based on the module name when updating the module. A test support system comprising: a search means (3a) for extracting information; and an output means (5) for displaying information on test support processing results. 2. The database section (6) is provided with executable file creation information (6c) that associates executable file creation information for each module of the program to be tested, and the module is updated and a search means (3b) for searching and extracting modules that are combined and required by the program to be tested from the test compatible module table (6a) stored in the database section (6) based on the test name; and,
2. The test support system according to claim 1, further comprising processing means (4a) for creating an executable file based on executable file creation information (6c) based on the module extracted by said means. 3. A module test status table (6b) is provided in the database unit (6) that associates the relationship between called modules that are called from the test module and are tested in conjunction with each other. Execution means (2b) for recording the execution results of the called module called by the calling module and tested in conjunction with the module test status table (6b) of the database unit (6), the test progress of the module, and the status of the remaining tests. When determining the status of a test, a search means (3c) extracts a corresponding table from the module test status table (6b) stored in the database section (6) based on the program name, and 2. The test support according to claim 1, further comprising processing means (4b) for dividing the number of modules executed by the number of target modules to be tested and creating a test progress status expressed as a ratio and a list of untested modules. system.