JPH06250884A - Device for supporting module test - Google Patents

Abstract

PURPOSE:To provide a module test supporting device capable of efficiently executing a module single body test. CONSTITUTION:An automatic driver generating part 6 automatically generates a driver 19 being a module for calling out a module to be tested based upon tested module information stored in an intermediate file 18. An automatic stub generating part 7 automatically generates a stub 20 being a module for simulating the operation of the low-order module of module to be tested based upon the tested module information stored in the file 18. An automatic debugger control command string generating part 8 specifies both the set position of the input data of a variable necessary for the execution of the module to be tested and a field to be practically used in an execution sentence and automatically generates a debugger control command for promoting the confirmation of setting and a result of the input data.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a device for supporting a test process, especially a module unit test, in a distributed cooperative development by a plurality of persons of a large scale software having a module structure.

[0002]

2. Description of the Related Art In recent years, the ratio of software to practical products has increased significantly, and there is an urgent need to improve software development efficiency. Especially, the labor required for the test process accounts for about half of the operation required for the entire development process, and the efficiency of the test process is an important issue.

Subprograms, subroutines, or procedures of one program are called modules, and testing them is called a module test. In a module test of large-scale software having a module structure, input parameters are set. Pseudo program that starts a module (hereafter called a driver)
Or, many pseudo programs (hereinafter referred to as stubs) of programs called by the module must be created. In addition, many input parameters and external variables that affect the operation of the module must be set to appropriate values according to the test conditions.

In a distributed development environment, ensuring high quality at the stage of source code creation, which is an independent process, greatly contributes to the efficiency of subsequent processes. The module test targeting the source module unit, which is a program component, meets this purpose, but it takes a lot of time to prepare the test environment and set the data as described above, which is a major obstacle.

Various methods have been proposed for automatic generation of stubs and drivers and setting of input parameters, etc., but test cases (input and expected output) are encoded in advance in a non-procedural language and saved in a database. However, there are some that perform an automatic test based on this (DJPanzl 'Autom
atic Software Test Drivers, 'Computer, 11 (4), 197
8.). This can be used as a substitute for a stub in the case of top-down test, but it is necessary to write in advance a test case for a nonexistent module called from the module under test.

[0006]

However, today, as the scale of software increases and the modularization of modules progresses, the efficiency is increased by distributed / shared cooperative development. In the above method, it is necessary for each module. All test cases need to be created in advance, and if you want to automatically generate stubs, you can
Since it is necessary to create a case and perform the test from the top down, the operation is too large as a module unit test support, and the advantage of distributed parallel development may be impaired.

Further, focusing on the creation of the test case, the value of the input data that is not actually referred to in the module under test must be set.

An object of the present invention is to provide a module test support device capable of efficiently performing a module unit test.

[0009]

A first module test support device of the present invention is a driver automatic generation means for automatically generating a driver, which is a module for calling a module under test, based on information about the module under test. , A stub that automatically generates a stub that is a module that simulates the operation of the lower module of the module under test, based on the information of the module under test, and the input data of the variables necessary for the execution of the module under test. Debugger control command sequence automatic generation means that automatically generates a debugger control command sequence file that specifies the setting location and the field that is actually used in the execution statement, sets the input data, and prompts you to check the result. Have.

A second module test support device of the present invention is a test data extraction / registration means for extracting a test case from a test log and registering it in a test data management file, and a driver, a stub and a debugger which are automatically generated after revision. The control command sequence file is compared with the debugger control command sequence file to which the pre-revision driver, stub, and pre-revision test case are added, and the reusable test case is extracted from the test data management file and its input And a test data reuse means for generating a batch mode debugger control command sequence file in which information / output information is embedded.

[0011]

The present invention specifically performs the following.

(A) A driver that calls a module under test and a stub called from the module under test are automatically generated. It also suspends execution when the driver calls the module under test, suspends execution when the stub is called from the module under test, outputs stub input parameters, and returns results to the module under test by the stub. Suspend execution on return, suspend execution when the driver receives a result from the module under test, and output parameter values for the module under test (if they have a structure, act within the module under test). Automatically generate a debugger control command string to display each field that may be received.

(B) When the module under test is a process definition, the driver and stub for this module under test are automatically generated. It also suspends execution when the driver starts the module under test, suspends execution when the stub is called from the module under test, outputs stub input parameters, and returns the stub to the module under test. Automatically generate a debugger control command string that suspends execution when returning.

(C) When the module activated by the module under test is a process definition, a stub for simulating this is automatically generated and a pseudo process for a process relating to signal transmission / reception of the module under test. In addition, the execution is suspended when the process sends a signal to the module under test waiting for signal reception, and the execution is suspended when the process is activated by the module under test,
A debugger control command sequence for automatically outputting the parameters received by the started process, suspending the execution when another process receives a signal from the module under test, and outputting the signal is automatically generated.

(D) Of the input parameters and externally defined variables of the module under test, the element names used in the module under test and their type definitions, and if these have a structure, only the necessary fields and their type definitions Of the output parameters of the externally defined module that are displayed and called by the module under test, only the element names and their type definitions used within the module under test, and if these have a structure, only the required fields and their type definitions. Automatically generate the debugger control command string to be displayed.

(E) Among the names and parameters of the signals received by the module under test waiting for signal reception from the process of transmitting signals to them, the elements used in the module under test and their type definitions, and these If has a structure, it automatically generates a debugger control command string that displays only the required fields and their type definitions.

(F) In addition to the automatically generated stub, driver, and debugger control command sequence, the information input by the tester and the debugger output result information are held in the system. When the module under test is changed, the debugger control command sequence before the change is compared with that after the change, the temporary stop command portion of the execution is associated, and the input information of the tester at the time of the temporary stop is changed. It is automatically added to the command string file. Also, the corresponding parts of the debugger output result information obtained in the test of the changed module and the output information for the module before the change held in the system are automatically extracted, and the corresponding parts are compared and compared. Automatically determine whether or not you are doing.

According to the above (A), the driver and the stub are automatically generated, it is not necessary for a human to bother to code or rewrite the source code, and the output result of the module under test can be easily confirmed. In addition to this, the setting of the input parameter value and the output parameter value of the stub can be easily and minimally performed by the above (D).

By the above (B), the above operation is possible even when the module under test has a process definition.

According to the above (C), even when the module under test activates a process or transmits / receives a signal, a stub for this is automatically generated, and it is necessary for a human to bother to code or rewrite the source code. Disappears. Moreover, in addition to this, the setting of the signal transmitted from the stub can be easily and minimally performed by the above (E).

By the above (F), it is possible to reproduce the test once performed, and it is possible to minimize the work for retesting the module in which the change has occurred.

[0022]

Embodiments of the present invention will now be described with reference to the drawings.

Here, an embodiment for large-scale software development by the CHILL language will be shown. A group of related data definitions, procedure definitions, large process definitions, etc. is called a CHILL module to distinguish it from a module of a subprogram, a subroutine, or a procedure in a program.

FIG. 1 is a block diagram of a module test support device according to an embodiment of the present invention.

The module test support device 1 is an input / output device 4
And a processing device 2 and a storage device 3. The processing device 2 includes a syntax / semantic analysis unit 5, a driver automatic generation unit 6, a stub automatic generation unit 7, a debugger control command sequence automatic generation unit 8, a compiler / linker 9, a debugger 10, a log generation unit 11, and a test data extraction unit 12. The test data registration unit 13 and the test data reuse unit 14 are included.
The storage device 3 includes a user work area 15 and a test data management file 16. The function of each unit will be described later.

FIG. 2 is a block diagram of the device during a module unit test.

First, the module under test 17, which is a source program, is input to the syntax / semantic analysis unit 5 to obtain an intermediate file 18 containing the source code information subjected to the syntax / semantic analysis. The driver automatic generation unit 6, the stub automatic generation unit 7, and the debugger control command sequence automatic generation unit 8 described below respectively use the intermediate file 1
Each file is generated based on the information stored in 8.

The driver automatic generation unit 6 uses the intermediate file 1
The driver 19 is created according to the following procedure based on the information on the module under test stored in FIG. First, the presence / absence of input / output parameters is checked. It is checked whether the module under test has an input parameter or an output parameter. When accompanied by a parameter, the variable name of the parameter and the type definition information are extracted from the intermediate file 18, and the type definition statement and the parameter are added to the driver module file. Describe the call statement of the module under test. Here, no value is set for the input parameter. If no parameter is included, describe only the call statement of the module under test. However, the module under test call description differs depending on whether the module under test is a procedure (PROC) or a process (PROCESS). Second, check whether the module under test receives a signal from another process. If a signal is to be received, a start statement of a stub program that sends a signal to the module under test is added to the driver module 19. Third
First, check whether the module under test sends a signal to another process. If a signal is to be transmitted, a start statement of a stub program that receives a signal from the module under test is added to the driver module 19.

Next, the stub automatic generation unit 7 will be described. A stub is a procedure or process that is called by the module under test, or a process that sends or receives signals to or from the module under test. (1) If the module under test calls a procedure of another CHILL module, this CHILL
Create a CHILL module with the same name as the module name,
Describe the procedure with the same name. Check whether the called module has an input parameter or an output parameter, and if it has a parameter, add a description regarding the variable definition. (2) Also, when the module under test activates the process, the same process is performed. However, for processes,
Write a process definition, not a procedure. (3) When the module under test receives a signal from another process, the process ID of the module under test is received as a parameter, and a CHILL module describing a process definition for transmitting a signal corresponding to the signal name to the ID is created. . If the signal has a parameter, add the definition statement of the parameter variable to make the description to send the signal with parameter. (4) When the module under test transmits a signal to another process, describe the process definition that receives the signal corresponding to the signal name.

Next, the debugger control command sequence automatic generation unit 8 will be described. The features of the exchange program actually targeted in this embodiment include: complex procedure call relationships; holding state as static data; passing parameters in list format. Considering these characteristics, consider the following input-output model. That is, the input parameter of the program under test, the reference static data, the output parameter of the procedure call, the reception signal is input, the output parameter of the program under test, the setting static data, the input parameter of the procedure call, the transmission signal is output, and the input information The test case is defined by the set, and the result is judged by the set of output information.

The driver 19 and the stub 2 generated by the driver automatic generation unit 6 and the stub automatic generation unit 7 described above.
In 0, the input data is not set. The debugger control command sequence automatic generation unit 8 generates a debugger control command sequence file 21 for interactively prompting the setting of the input data and the confirmation of the output information. That is, the input data setting location is specified, and the field of the input that is actually used in the execution statement is specified. The details will be described below.

The input is the driver 19
These are parameters received from, static data, return data of procedure calls, and received signals. The debugger control command sequence automatic generation unit 8 is an intermediate file 1 obtained by parsing the source code.
8 and the automatically generated source information of the driver 19 and stub 20 where the driver 19 calls the module under test, where static data is first used, and the stub 20 returns to the module under test The location where the data is passed and the location where the stub 20 sends the signal to the module under test are specified. Next, it is specified what kind of structure those inputs have, what fields of which inputs are actually used in the executable statement of the module under test. In this way, the debugger control command sequence automatic generation unit 8 describes a command for stopping the execution at the place where data setting is required, and executes the debugger command at the time of the stop, that is, which field of the variable needs to be set, A command description that indicates what type of data should be set, a command that receives and sets the tester's input data, and a command that automatically resumes execution after setting the data are described in association with the stop command. As a result, the debugger control command sequence file 21 is generated.

On the other hand, the output is return data to the driver 19 of the module under test, static data set (changed) in the module under test, input parameters at the time of procedure call or process activation, and transmission signal. Debugger control command sequence automatic generation unit 8
Is the same as in the case of input, where the driver 19 receives return data from the module under test, where static data is set, where the stub 20 is called (started) by the module under test, and stub 20 is Identify each location that receives the signal. Next, it identifies which variable field was changed by the executable statement of the module under test. In this way, the debugger control command sequence automatic generation unit 8 outputs the command for stopping the execution at the place where the output data confirmation is required and the data requiring the confirmation at the time of the stop, and the change is caused especially by the execution of the module under test. In the variable control field, commands to be displayed with a mark to show them are described in the debugger control command sequence file 21, respectively.

Next, the test data extraction unit 12 and the test data registration unit 13 will be described. Since the exchange program has a set of a plurality of input data and a set of output data due to the above-mentioned features, it is very troublesome to create in advance. On the other hand, when an input data set is given interactively as in the present invention, one issue is how to extract the test case in consideration of the retest, but the test data extraction unit 12 and the test data registration unit 13 Solve this by.

The developer (tester) is the module under test,
The load module 22 is generated by the compiler / linker 9 from the driver 19 and the stub 20 and loaded into the debugger 10. Then, according to the procedure specified by the debugger control command sequence file 21,
Set the input information and check the output information. Debugger 10
All of these steps above are saved in the test log file 23 generated by the debugger 10. The test data extraction unit 12 extracts an input information set and an output information set based on the test log file 23, and the test data registration unit 13 registers and manages the test data management file 16 which is a test case database.

FIG. 3 is a block diagram of the apparatus at the time of retesting the module.

At the time of revision of the source code to be tested, retesting is required to confirm the degradation. However, it is generally difficult to divert the debugger control command sequence file and the test case file as they are to the retest at the time of revision. The test data reuse unit 14 applies the test information before revision stored in the test data management file 16 by the test data extraction unit 12 and the test data registration unit 13 to the retest as much as possible by the following method. To do. Specifically, the driver 19 and the stub 2 which are automatically generated by this apparatus from the revised source program 17
0, the debugger control command sequence file 21 and the corresponding files 19 ', 20', and 21 'before the revision are compared with each other, and in particular, the correspondence relationship at the execution stop portion is checked to extract a reusable test case. The source line position shift at the stop point is dynamically matched by comparing the executable statements. Then, by embedding the input information and output information of valid test cases in the debugger control command sequence file 21 for the source code test after revision, automatic input data setting and automatic result determination can be performed for reusable parts. Generate a retest debugger control command sequence file 24 for mode. As a result, the developer may manually test only the test cases generated by the source code modification according to the support of the retest debugger control command sequence file 24.

[0038]

As described above, the present invention has the following effects. (1) According to the first aspect of the invention, the tester sets the minimum input data necessary for the execution of the module under test and automatically outputs the output data by automatically generating the driver, stub, and debugger control command sequence files. Since it can be confirmed by the interactive method, the module unit test can be efficiently performed. Further, the quality of the module in the test process after the module test (such as the coupling test process) is improved, and the rework when a bug exists in the module can be reduced, so the time required for the test process can be shortened. In addition, the test information ensures the quality of the version-controlled module. (2) According to the second aspect of the present invention, when a module is changed or modified, the module unit test can be efficiently performed by reusing the test resources performed for the module before the change.

[Brief description of drawings]

FIG. 1 is a configuration diagram of a module unit test support device according to an embodiment of the present invention.

FIG. 2 is a device configuration diagram during a module unit test.

FIG. 3 is a device configuration diagram at the time of a module retest.

[Explanation of symbols] 1 module test support device 2 processing device 3 storage device 4 input / output device 5 syntax / semantic analysis unit 6 driver automatic generation unit 7 stub automatic generation unit 8 debugger control command sequence automatic generation unit 9 compiler / linker 10 debugger 11 Log Creation Section 12 Test Data Extraction Section 13 Test Data Registration Section 14 Test Data Reuse Section 15 User Work Area 16 Test Data Management File 17 Source Program 18 Intermediate File 19, 19 'Driver 20, 20' Stub 21, 21 ' Debugger control command sequence file 22 Load module 23 Test log file 24 Retest Debugger control command sequence file

Claims (2)

[Claims] 1. Data for inputting variables necessary for executing a module under test by an interactive method for a module test of large-scale software composed of a plurality of modules that are subprograms, subroutines, and procedures in a program. Is a module test support device for setting and confirming output data, and a driver automatic generation means for automatically generating a driver, which is a module for calling a module under test, based on module information under test, Automatic stub generation means that automatically generates a stub that is a module that simulates the operation of the lower module of the test module based on the information of the module under test, and the setting location of the input data of the variables required to execute the module under test. The fields that are actually used in the executable statement. And a module test support device having a debugger control command sequence automatic generation means for automatically generating a debugger control command sequence file prompting the setting of input data and confirmation of the result. 2. A test data extraction / registration means for extracting a test case from a test log and registering it in a test data management file, a driver, stub and debugger control command sequence file automatically generated after revision, and a driver before revision. , A stub, and a debugger control command sequence file to which test cases before revision are added are compared, reusable test cases are extracted from the test data management file, and input / output information of the batch mode is embedded. A module test support device having a test data reuse means for generating a debugger control command sequence file.