JPH0243638A - Driver for program test - Google Patents

Abstract

PURPOSE:To decrease cost without preparing a driver and a stub for a program to be tested by providing a parameter data file. CONSTITUTION:A parameter data file 3 has respective program names of programs to be tested at a program name area 3-1, and respective parameter data of the programs to be tested are beforehand written in a parameter data area 3-2. The program to be tested reading executing part 1-3 of a driver 1 for a program test reads the test object program including the tested program selected by a tested program selecting part 1-1 at a test object program storing area 4, designates the selected program to be tested, operates with the parameter read by a parameter input part 1-2 and thus, the test of the selected program to be tested is executed. Thus, the driver and the stub are not necessary for the tested program.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a program test driver, and more particularly to a program test driver for executing tests of various programs.

[Conventional technology]

Traditionally, there are bottom-up testing methods and top-down testing methods as testing methods for programs that are components of business programs with a modular structure. This is done by creating a stub, which is a dummy module that maintains an interface with the program under test, for each program under test.

Note that such program testing is performed individually on each completed program even if the entire business program having a modular structure is not yet completed.

[Problem to be solved by the invention]

The above-mentioned conventional program test has the disadvantage that a driver and a stub are required for each program under test, and creating these requires high costs.

Another problem is that conventional drivers and stubs are mainly used individually during program creation and are not grouped together for the entire business program, so they are rarely used after the entire business program is completed. There is.

An object of the present invention is that compared to creating a driver or stub for each program under test, it can be created and used at a lower cost, and it is possible to test each component of a business program.
To provide a program test driver capable of easily identifying problems by conducting a program test as necessary even after the entire business program is completed.

[Means to solve the problem]

The program test driver of the present invention includes (A) a program under test selection section that inputs a program name from an input device and selects a program under test indicated by the program name; (C) a parameter input section for reading parameter data for the program under test selected by the program under test selection section from a parameter data file in which necessary parameter data is written in advance; (C) the program under test selection section; By reading out the test target program including the program under test selected by the section into the test target program storage, specifying the selected program under test, and operating it using the parameter data read out at the parameter input section. , a program under test reading execution unit that executes a test of the selected program under test; (D> a test result output unit that outputs test result information of the program under test executed by the program under test reading execution unit to an output device; It is configured with.

〔Example〕

Next, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing an embodiment of a program test driver of the present invention.

As shown in FIG. 1, the test program selection section 1-1 of the program test driver 1 receives
The program name of a program that is a component of a business program having a module structure is input, and the program to be tested indicated by the program name is selected.

FIG. 2 is a program configuration diagram showing an example of the constituent elements of a business program having a module structure.

As shown in FIG. 2, the business program 6 has a main program M at level -0, which is the highest level of the module structure, and subprograms A and B at the next level -1.
It has subprograms C, D, and E at the lowest level-2.

Further, the parameter input unit 1-2 of the program test driver 1 inputs parameter data necessary for testing each of the programs under test from the parameter data file 3 written in advance. Parameter data for the program under test selected in step 1 is being read.

FIG. 3 is a data configuration diagram showing an example of the contents of a parameter data file.

As shown in FIG. 3, the parameter data file 3 is
The program name area 3-1 has each program name of the program under test, and the parameter data area 3-2
Each parameter data of the program under test is written in advance.

Therefore, the program under test read execution section 1-3 of the program test driver 1 reads out the program under test including the program under test selected by the program under test selection section 1-1 into the program under test storage 4, and selects the program under test. By specifying the selected program under test and operating it using the parameter data successively inputted from the parameter input section 1-2, the selected program under test is tested.

FIG. 4 is an operational explanatory diagram showing an example of the operation of the program under test reading execution section.

As shown in FIG. 4, when the program under test reading execution unit 1-3 specifies and operates subprogram A using the CALL A-parameter, subprogram A also calls and executes subprogram C. There is.

Further, the program under test reading execution unit 1-3 performs CA
When subprogram B is designated and operated using the LL B-parameter, subprogram B also calls and executes subprograms D and E.

On the other hand, the program under test reading execution units 1-3 each CALL C-parameter.

Subprograms C and D are created by CALL D-parameter and CALL E-parameter, respectively.

When E is specified and operated, only subprograms C, D, and E are executed.

As a result, the test result output section 1-4 of the program test driver 1 outputs the program under test reading execution section 1-4.
The test result information of the program under test executed in step 3 is output to the output unit 7! It is output to L5.

As described above, the program test driver of this embodiment can be created and used at a lower cost than creating a driver or stub for each program under test, and can be used to construct a unified business program. Since each element can be tested, even after the entire business program is completed, program tests can be performed as needed to easily identify problems.

〔Effect of the invention〕

As explained above, the program test driver of the present invention can be created and used at a lower cost than creating a driver or stub for each program under test, and can be used as a component of a unified business program. Since tests can be carried out for each of the above, even after the entire business program is completed, program tests can be carried out as needed to easily identify problems.

Fig. 1 is a block diagram showing an embodiment of the program test driver of the present invention, Fig. 2 is a program configuration diagram showing an example of the constituent elements of a business program having a module structure, and Fig. 3 is the content of the parameter data file. FIG. 4 is an operation explanatory diagram showing an example of the operation of the program-under-test reading execution unit.

1... Driver for program test, 1-1.
...Program under test selection section, 1-2...
...Parameter input section, 1-3...Test program reading execution section, 1-4...Test result output section, 2...Input device, 3... ...Parameter data file, 3-1...Program name area, 3-2...Parameter data area, 4
... Test target program memory castle, 5...
...Output device, 6...Business program, A, B
, C, D, E... Subprogram, M...
...Main program.

Claims (1)

[Claims] (A) A program to be tested selection unit that inputs a program name from an input device and selects a program to be tested indicated by the program name; (B) Parameters necessary for testing each of the programs to be tested. (C) a parameter input section for reading out parameter data for the program under test selected by the program under test selection section from a parameter data file written in advance; The program under test including the selected program under test is read into the test target program memory, the selected program under test is specified, and the selected program is operated using the parameter data read out in the parameter input section. (D) a test result output unit that outputs test result information of the program under test executed by the program under test read execution unit to an output device; A program test driver featuring: