JP3119400B2 - Module test support equipment - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

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

[0002]

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

A subprogram, subroutine, or procedure of one program is called a module, and testing them is called a module test. In a module test of a large-scale software having a module structure, input parameters are set and the parameters are set. Pseudo program that starts the module (hereinafter called driver)
In addition, many pseudo programs (hereinafter, referred to as stubs) of programs called by the module must be created. In addition, appropriate values must be set for a number of input parameters and external variables that affect the operation of the module 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 the post-process. The module test for each source module, which is a program component, meets this purpose, but it takes a long time to prepare the test environment and set 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 and the like. However, test cases (inputs and expected outputs) are coded in a non-procedural language in advance and stored in a database. Some of them perform automatic tests based on this (DJPanzl 'Autom
atic Software Test Drivers, 'Computer, 11 (4), 197
8.). Although this can be used as a substitute for a stub in the case of a top-down test, it is necessary to write a test case for a non-existent module called from a module under test in advance.

[0006]

However, while the software scale has been increasing and the module structure has been advanced today, the efficiency has been improved by distributed and shared cooperative development. It is necessary to create all test cases in advance, and when trying to automatically generate stubs, test
Since cases must be created and tested from the top down, the operation is too large to support module unit testing, and the advantages of distributed parallel development may be impaired.

In addition, if attention is paid to the creation of a test case, it is necessary to set input data values that are not actually referenced in the module under test.

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

[0009]

[0010] A module test support apparatus of the present invention extracts test cases from a test log and registers them in a test data management file, and a driver, stub, and debugger control command sequence automatically generated after revision. The file is compared with a debugger control command string file to which a driver, stub, and a test case before the revision are added, and a reusable test case is extracted from the test data management file.
Test data reuse means for generating a batch mode debugger control command string file in which output information is embedded.

[0011]

The present invention specifically performs the following.

(A) A driver for calling 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, pauses execution when the stub is called from the module under test, outputs stub input parameters, and outputs the result to the module under test. Suspend execution at the time of return, suspend execution at the time the driver receives the result from the module under test, and output parameter values of the module under test (if they have a structure, Automatically generates a debugger control command sequence for displaying each of the fields that may be received.

(B) When the module under test has a process definition, a driver and a stub for the 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 outputs the stub to the module under test. Automatically generates a debugger control command sequence that suspends execution when returning.

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

(D) Of the input parameters and externally defined variables of the module under test, only 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 to be displayed and called by the module under test, only the element names used in the module under test and their type definitions, and if they have a structure, only the necessary fields and their type definitions Automatically generate a debugger control command string to be displayed.

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

(F) In addition to the automatically generated stub, driver, and debugger control command strings, information input by the tester and debugger output result information are stored in the system. Then, when the module under test is changed, the debugger control command sequence before the change is compared with that after the change, the execution pause command portion is associated, and the tester input information at the time of the pause is changed after the change. Automatically add to command string file. In addition, a corresponding portion between the debugger output result information obtained in the test of the module in which the change occurred and the output information of the module before the change held in the system is automatically extracted, and the corresponding portion is compared. Automatically determine whether or not

According to the above (A), the driver and the stub are automatically generated, so that there is no need for a person to code or rewrite the source code, and the output result of the module under test can be easily confirmed. In addition, according to the above (D), the setting of the input parameter value and the output parameter value of the stub can be easily and minimized.

According to the above (B), even when the module under test has a process definition, the above operation can be performed.

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

According to the above (F), it is possible to reproduce the test once performed, and it is possible to minimize the work of retesting the changed module.

[0022]

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

Here, an embodiment for large-scale software development using the CHILL language will be described. A collection of related data definitions, procedure definitions, large process definitions, and the like will be referred to as a CHILL module to distinguish them from subprograms, subroutines, and procedure modules in a program.

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

The module test support device 1 includes 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, an automatic driver generation unit 6, an automatic stub generation unit 7, an automatic debugger control command sequence generation unit 8, a compiler / linker 9, a debugger 10, a log generation unit 11, and a test data extraction unit 12. And a test data registration unit 13 and a test data reuse unit 14.
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 diagram showing the configuration of the apparatus during the module unit test.

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

The driver automatic generation unit 6 stores the intermediate file 1
The driver 19 is created in the following procedure based on the information on the module under test stored in 8. First, the existence of input / output parameters is checked. It checks whether the module under test has an input parameter or an output parameter. If a parameter is involved, the parameter name and type definition information of the parameter are extracted from the intermediate file 18 and the description of the type definition statement and the parameter Each of the call statements of the module under test is described. Here, no value is set for the input parameter. If no parameter is involved, 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, it checks whether the module under test receives a signal from another process. If a signal is received, an activation statement of a stub program for transmitting a signal to the module under test is added to the driver module 19. Third
Next, it is checked whether the module under test transmits a signal to another process. If a signal is to be transmitted, an activation statement of a stub program for receiving a signal from the module under test is added to the driver module 19.

Next, the automatic stub generation unit 7 will be described. The stub includes a procedure or process called by the module under test, and a process of transmitting or receiving a signal from the module under test. (1) When a procedure of another CHILL module is called by the module under test, this CHILL module
Create a CHILL module with the same name as the module name,
Write a procedure with the same name. Check whether the called module has an input parameter or an output parameter, and if so, add a description about the variable definition. (2) When the module under test starts a process, the process is performed in the same manner. However, for processes,
Write process definitions, not procedures. (3) When the module under test receives a signal from another process, a CHILL module that describes a process definition for receiving the process ID of the module under test as a parameter and transmitting a signal corresponding to the signal name to the ID is created. . If the signal has parameters, add a parameter variable definition statement to describe the transmission of the signal with parameters. (4) When the module under test transmits a signal to another process, a process definition for receiving the signal corresponding to the signal name is described.

Next, the debugger control command sequence automatic generation section 8 will be described. The features of the exchange program actually targeted in this embodiment include: the procedure call relationship is complicated; the state is held as static data; and the parameters are delivered in a list format. Considering these characteristics, consider the following input-output model. That is, the input parameters of the program under test, the reference static data, the output parameters of the procedure call, the received signal are input, the output parameters of the program under test, the set static data, the input parameters of the procedure call, and the transmission signal are output, and A test case is defined by a set, and a result is determined by a set of output information.

The driver 19 and the stub 2 generated by the automatic driver generation unit 6 and the automatic stub generation unit 7 described above.
0 indicates that the input data has not been 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 executable statement is specified. The details will be described below.

The input is that the module under test is
Parameters, static data, procedure call return data, and received signals. The debugger control command sequence automatic generation unit 8 analyzes the intermediate file 1 obtained by parsing the source code.
8, the driver 19 calls the module under test, the location where the static data is used first, and the stub 20 returns to the module under test based on the automatically generated driver 19 and source information of the stub 20. The location where data is passed and the location where the stub 20 sends a signal to the module under test are specified. Next, it specifies what kind of structure those inputs have and 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 the command to stop the execution at the place where the data setting is required, and executes the debugger command to be executed at the time of the stop, that is, which field of the variable needs to be set, and A command description that indicates what type of data should be set, a command that receives and sets tester input data, and a command that automatically resumes execution after setting data are described in association with stop commands. Thereby, 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 startup, and transmission signals. Debugger control command sequence automatic generation unit 8
In the same manner as in the case of input, a place where the driver 19 receives return data from the module under test, a place where static data is set, a place where the stub 20 is called (activated) by the module under test, and Identify each location to receive a signal. Next, it specifies which variable field has been changed by the executable statement of the module under test. In this way, the debugger control command sequence automatic generation unit 8 outputs a command to stop execution at a place where the output data needs to be confirmed, and outputs data that needs to be confirmed at the time of the stop. Commands to be displayed with a mark for recognizing them in the variable field are described in the debugger control command sequence file 21, respectively.

Next, the test data extracting unit 12 and the test data registering unit 13 will be described. Due to the above-mentioned characteristics, the exchange program has a set of a plurality of sets of input data and a set of output data, so that it is very time-consuming to prepare in advance. On the other hand, when an input data set is provided in an interactive manner as in the present invention, one problem is how to extract test cases in consideration of retests. However, the test data extraction unit 12 and the test data registration unit 13 To solve this.

The developer (tester) includes a module under test,
A load module 22 is generated from the driver 19 and the stub 20 by the compiler / linker 9 and loaded into the debugger 10. Then, according to the procedure defined by the debugger control command sequence file 21,
Set the input information and check the output information. Debugger 10
All of the above steps are stored in a 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 information in a test data management file 16 which is a test case database.

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

When the source code under test is revised, a retest is required to confirm the degrade. However, in general, it is difficult to use the debugger control command sequence file and the test case file as they are for retesting at the time of revision. The test data reuse unit 14 applies the test information before the revision, which is made into a database 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. I do. Specifically, the driver 19 and the stub 2 automatically generated by the apparatus from the source program 17 after the revision
0, the debugger control command sequence file 21 is compared with the corresponding files 19 ', 20', 21 'before the revision, and the correspondence between execution stop portions is particularly checked, and a reusable test case is extracted. The displacement of the source line position at the stop point is dynamically matched by comparing executable statements. Then, the input information and the output information of the valid test case are embedded in the debugger control command string file 21 for the source code test after the revision, so that the reusable part can be set with automatic input data setting and automatic result judgment. A mode retest debugger control command sequence file 24 is generated. This allows the developer to manually test only the test cases generated due to the source code modification in accordance with the support of the retest debugger control command sequence file 24.

[0038]

As described above, according to the present invention, when a module is changed or modified, the module unit test is efficiently performed by reusing the test resources performed on the module before the change. be able to.

[Brief description of the drawings]

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

FIG. 2 is an apparatus configuration diagram at the time of a module unit test.

FIG. 3 is an apparatus configuration diagram at the time of module retest.

[Explanation of symbols]

 REFERENCE SIGNS LIST 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 generation unit 12 Test data extraction unit 13 Test data registration unit 14 Test data reuse unit 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 string file

Continuation of the front page (58) Field surveyed (Int.Cl. ⁷ , DB name) G06F 11/28 340 G06F 9/06 540

Claims (1)

(57) [Claims] 1. A test data extraction / registration means for extracting a test case from a test log and registering the test case in a test data management file, a driver, stub and debugger control command string file automatically generated after the revision, and a driver before the revision , A batch mode in which a stub and a test case before the revision are added to a debugger control command string file, a reusable test case is extracted from the test data management file, and input information / output information thereof is embedded. A module test support device having test data reuse means for generating a debugger control command string file.