JPH0619731B2 - Program unit test method - Google Patents

Description

The present invention relates to a program unit test method for individually testing each module program of a program composed of a plurality of modules, and in particular, another related module is created. It relates to a unit test method of a program that can be tested without it.

Generally, in a large system, a program is rarely composed of one module (compilation unit), and is hierarchically structured so that a plurality of modules are collected to perform one processing.

For example, as shown in FIG. 5, a module B is configured as a subroutine of the module A, and modules C and D are configured as a subroutine of the module B to configure one program. In order to develop such a hierarchical program, the order in which the modules are created is determined in consideration of the efficiency of the test, and generally after the system is designed as shown in FIG. 6, the modules A, B, C, D is created.

As a procedure of this development, there are a top-down method created from the upper module A and a bottom-up method created from the lower module C or D.

[Conventional technology]

In order to test a program in which each module is structured hierarchically, it is desirable to test the program after all modules are completed, but in the case where each module is created sequentially, It is more efficient in terms of development procedure to test the module by itself each time each module is created.

However, even if a module is tested by itself, the hierarchical program structure cannot be tested unless other related modules exist. For example, when testing Module A, you need Module B,
When testing module B, use modules A, C,
D is required. Therefore, in the past, the tester created a temporary module related to the module to be tested,
I was doing a unit test of the module.

For example, in order to test the module B, a temporary module of the upper module A (called a driver) and a temporary module of the lower modules C and D (called a stub) are created.

[Problems to be solved by the invention]

The drivers and stubs required for testing such modules are temporary modules, so they can be made small and easy. However, as with normal program creation, the coding and testing steps are required, and the drivers and stubs for unit testing are required. However, there was a problem that the development of was required for each module individually.

In order to solve this, a test method provided with a stub function for substituting a lower module of a module under test has been proposed (for example, Japanese Patent Laid-Open No. 58-175061).

Even with this, there were the following problems.

Since there is no substitute function for the upper module, only top-down programming can be applied, and bottom-up programming and unit testing in a mixture of both cannot be performed.

When substituting a lower module, it is necessary to set a used area and the like, and it takes time to set data.

[Means for solving problems]

Therefore, it is an object of the present invention to provide a unit test method of a program capable of analyzing a module under test, detecting the presence of upper and lower modules, and automatically setting upper and lower alternative functions. . Therefore, according to the present invention, in a unit test method of a program in which a processor executes a test of a module unit of a program in which a plurality of modules are hierarchically structured, the module under test is analyzed to determine the upper and lower levels. A test support tool for detecting the presence of a module and performing an alternative function of an upper or lower module is provided. When the presence of the upper module is detected, the test support tool provides a parameter to be passed to the module under test. After the area is secured in the memory and the test data is set, the module under test is activated, and when the presence of the lower module is detected, the parameter area is obtained in the memory and the test of the module under test is performed. A test passed to the module under test in response to the submodule being called during execution. Data is set in the parameter area and passed to the module under test.

[Action]

In the present invention, a test support tool (program) is provided, and this support tool automatically executes the driver or stub function. That is, the support tool analyzes the module under test, extracts the interface (connection) information of the upper or lower module contained therein, detects the existence of the upper or lower module, and when the upper module exists, the module under test is detected. Prior to the start of, the parameter area is secured in the memory based on the interface information, the test data given from the outside is set in this area, and the test start of the module under test is performed. , Test data externally given from interface information in response to calling a lower module during test execution of the module under test is set in a memory and passed to the module under test to continue the test of the module under test. I am trying.

〔Example〕

 Hereinafter, the present invention will be described in detail with reference to Examples.

FIG. 1 is a block diagram of an embodiment of the present invention, in which 1
Is a computer (processor), which executes a program to perform desired processing, 10 is an OS (operating system) section thereof, which controls the entire computer 1, 11 is a module analysis section,
As described below, the logic design information described in the logic design language is analyzed to create a COBOL source program, and the interface (debug) information is extracted, 1
Reference numeral 2 is a COBOL compiler, which converts a source program into a load module in a format that can be executed by a computer, and 13 is a test support tool unit, which performs a driver / stub function from interface information as described later. The OS unit 10, the module analysis unit 11, the COBOL compiler 12, and the test support tool unit 13 are blocks of the functions executed by the computer 1. 2 is a file memory for storing various files, 20 is a logical design information file for storing later-described logical design information created by a programmer, 21 is a COBOL source file, and a module CO created by the analysis unit 11
A BOL source program is stored, 22 is a debug information file, and interface information extracted by the module analysis unit 11 is stored, 2
3 is a load module file, which stores the load module created by the COBOL compiler 12, 24 is a test data file, which stores the test data input by the operator, 3 is a console, It consists of a display and a keyboard and is operated by an operator to input logic design information and test data.

Next, the operation of the configuration of the embodiment shown in FIG. 1 will be described with reference to the process flow diagram of FIG. 2, the logical design information explanatory diagram of FIG. 3, and the operation explanatory diagram of the test support tool of FIG.

The operation of a program programmed by a well-known high-level logic design language will be described below.

As shown in FIG. 3, programming in the logical design language is common to each module A, B, C, D, format definition document (FIG. 3 (A)), interface definition document of each module (FIG. 3 (B)). ), A module definition document (Fig. 3 (C)) for each module is created. This common format definition document defines the format of items (data), the number of digits, etc. that are common to each module.
The interface definition document is the input / output item of each module,
It is used to define a module name and the like, which is determined at the basic design stage and is stored in the logical design information file of the file memory 2 from the console 3 via the computer 1.

On the other hand, the module definition is created for each module,
The processing, logic, and conditions of the module are listed according to the procedure, and the programmer sequentially describes and programs necessary processing and the like for each module, and this shows the processing content of the module. The operator causes the console 3 to store the module definition document in the logical design information file 20 through the computer 1 every time the module definition document is completed.

For example, it is assumed that the module definition document of the module B is completed and stored in the logical design information file 20, and the other modules A, C and D are not completed.

The operator activates the job control function of the OS unit 10 on the computer 1 from the console, and the COB of the module B
Command to create an OL source program. As a result, the module analysis unit 11 which is a kind of compiler
Reads the logical design information of the logical design information file 20,
Create a source program written in COBOL, and
It is stored in the OBOL source file 21. This COBO
The source program described in L is shown as a module under test in FIG. 4, for example, and corresponds to a program programmed in COBOL by a programmer without using a logic design language.

At the same time, the module analysis unit 11 extracts the interface information from the logic design information. For example, in the example of FIG. 3, the module B is called by the module A, the number of parameters is G1 and G2, and the area is A1, A.
The value of 2 is extracted from the interface definition document of module B, and the lengths of its parameters G1 and G2 are extracted from the common format definition document. Also, module B
The module C (days =% days calculation) and the calling of the module D are extracted from the module definition document, and the use area thereof is extracted from the interface definition documents of the modules C and D.

Looking at this from the description of the COBOL source program,
As described for the module under test in FIG. 4, A1 and A2 of the module A are used, B1 of the module C1 and B2 of the module D are used.

The module analysis unit 11 extracts the interface (module name, number of parameters, parameter area name, length, etc.) when the module B is called and the interface when the module B is called from the logical design information, and the debug information file It stores in 22.

In this way, the COBOL source program for the module B is created, and the interface information between the modules is extracted.

Next, a unit test of module B is performed.

Therefore, the operator stores the test data for testing the module B in the test data file 24 from the console 3 via the computer 1. Then, the operator inputs a test execution command into the computer 1. In the computer 1, the OS unit 10 causes the COBOL compiler 12 to operate, translates the COBOL source program of the module B of the COBOL source file 21 into a load module that can be executed by the computer 1, and stores the load module in the load module file 23. Next, the OS unit 10 activates the test support tool unit 13 to analyze the interface information of the debug information file 22.

The test support tool unit 13 analyzes the above-mentioned interface information as shown in the processing flow chart of FIG. 2 and detects whether or not a higher-order module exists. When the upper module exists, the driver function, that is, the upper module substitute function is executed. First, a parameter passing area to be passed to the module under test B is secured in an internal memory (not shown) of the computer 1. In the above-mentioned example, as shown in FIG. 4, the input / output areas of A1 and A2 are secured in the internal memory and their addresses are set.

Next, the console 3 displays an instruction of test data to the operator, and the operator instructs the test data of the test data file 24 from the console 3. As a result, necessary test data (input data from the upper module) of the test data file 24 is set in the area A1 of the internal memory.

This allows module B to perform processing using parameter A1. Incidentally, A2 is for outputting the execution result of the module B.

Next, the test support tool unit 13 instructs the OS unit 10 to activate the module under test.

The OS unit 10 executes the load module of the module B of the load module file 23, and executes using the parameter A1 of the module A therein.

While the test of the module B is being executed in this way, there is a "call" (call) instruction of the module C or D, and the OS unit 10 searches the load module file 23 If no is found, the test support tool unit 13 is notified of the error.

As a result, the test support tool unit 13 obtains the address of the parameter area (B1 or B2) of the internal memory prepared for the module under test to call the lower module,
The console 3 displays the test data instruction to the operator. The operator gives an instruction from the console 3 which test data in the test data file 24 is to be set. As a result, necessary test data (output data of the lower module) of the test data file 24 is set in the parameter area of the internal memory.

Therefore, the module under test B receives this test data as output data of the lower module and continues the test.

In this way, the test support tool unit 13 automatically executes the alternative function of the upper or lower module from the interface information, and tests the module under test.

In the above embodiment, an example of programming in the logic design language has been described, but a source program may be created by programming in COBOL. In this case, COBO
Interface information is extracted from the L source program. Although the operator gives an instruction from the console 3 to set the test data in the parameter area, this may be done automatically. Furthermore, the language of the source program is not limited to COBOL, but another language may be used.

Although the present invention has been described above with reference to the embodiments, the present invention can be variously modified according to the gist of the present invention, and these modifications are not excluded from the present invention.

〔The invention's effect〕

As described above, the present invention has the following effects.

Since the test support tool for detecting the existence of the upper and lower modules and performing the alternative function of the upper or lower module is provided, the unit test can be performed in both the top-down programming and the bottom-up programming.

Since the module under test is automatically analyzed and the presence of the upper and lower modules is detected and the alternative function is performed, the upper and lower alternative operations can be automatically executed.

When the presence of the upper module is detected, the area for the parameters to be passed to the module to be tested is secured in memory, the test data is set, and then the module to be tested is activated. I can do it.

When the presence of the lower module is detected, the parameter area is obtained in the memory, so the data setting becomes easy,
Can execute unit tests at high speed.

[Brief description of drawings]

FIG. 1 is a block diagram of an embodiment of the present invention, FIG. 2 is a process flow diagram of a test support tool of FIG. 1 embodiment configuration, and FIG. 3 is an explanation of a logic design language used in FIG. 1 embodiment configuration. Fig. 4 is an explanatory diagram of the operation of the test support tool of Fig. 1 embodiment configuration, Fig. 5 is an explanatory diagram of a hierarchical module configuration program, and Fig. 6 is a development procedure explanatory diagram of the program of Fig. 5. is there. In the figure, 1 ... computer (processor), 2 ... file memory, 3 ... console, 13 ... test support tool.

Claims (1)

[Claims] 1. In a unit test method of a program in which a processor executes a test of a module unit of a program in which a plurality of modules are hierarchically structured, the module under test is analyzed to determine the presence of upper and lower modules. And a test support tool for performing an alternative function of an upper or lower module is provided. When the presence of the upper module is detected, the test support tool stores a memory area for parameters to be passed to the module under test. , And after setting the test data, the module under test is activated, and when the presence of the lower module is detected, the parameter area is obtained in the memory and the test of the module under test is executed. , Test data to be passed to the module under test in response to the submodule being called Is set to the parameter area, unit test method program characterized by passing to said test module.