JPH07219810A - Module testing method and device therefor - Google Patents

Abstract

PURPOSE:To improve efficiency of the single program module test. CONSTITUTION:An interface file processing part 2 reads a file that includes the function to be tested and procudes the name of this function and a list of input/output parameters. A module definition editor processing part 3 inputs the name of the function and the parameter name of the function based on the parameter list. A module function automatic execution processing part 4 displays the input parameter name, etc., and inputs the proper value. Then the value is outputted in accordance with the set parameter value when the execution of the function is instructed. Therefore it is not required to produce the test programs for each module to be tested, and the test efficiency is improved.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a module test method capable of confirming the operation of a created module without creating a sample program or the like, and an apparatus using the same.

[0002]

2. Description of the Related Art Conventionally, when a final program (hereinafter called a target program) such as an application program is created, it is divided into a plurality of functional modules and created for each functional module. , The method of linking them is often done. In this case, the operation of the target program is usually verified by performing a unit test for each functional module. In this unit test for each functional module, the author himself creates a simple sample program separately from the target program, links each functional module to be tested to this sample program, and after linking Sample of
The program was run to check the operation of the functional module.

[0003]

In the above-mentioned conventional example, a work unrelated to the original purpose of "creating a sample program" occurs separately from the target program, and a sample is created for each target program. -The program had to be created and changed, which caused a decrease in development efficiency.

The present invention has been made in view of the above-mentioned conventional example, and an object thereof is to provide a unified, reusable module test method and an apparatus using the same.

[0005]

In order to achieve the above object, the module test method of the present invention has the following configuration. That is, a program module test method in an information processing system having a display,
A reading step of reading the interface information described in the program to be tested, a display step of displaying on the display a screen for setting data based on the interface information read by the reading step, and a screen displayed by the display step And an input step of inputting data according to the input step, and a step of executing the test target program based on the data input by the input step and the interface information.

Further, the module test apparatus of the present invention has the following configuration. That is, a module test device for testing a program for each module, the reading means for reading the interface information described in the program to be tested, and the screen for setting data based on the interface information read by the reading means are displayed. Display means for displaying on the display, input means for inputting data according to the screen displayed by the display means, and executing the test target program based on the data input by the input means and the interface information. And means.

[0007]

With the above configuration, a screen for setting data based on the interface information of the test target program is displayed, data corresponding to the screen is input, and the test target program is executed based on the input data.

[0008]

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

FIG. 1 shows the configuration of a test system for verifying the function of a module described in C language according to the present embodiment. In C language, a procedure is represented in the form of a function. The target program is obtained by linking a program created as a module file in which one or more functions are described. This test system performs a unit test for each module file and for each function in the module file. .

First, the structure of a program written in C language will be briefly described.

A function name is added to the function defined in the module file. Also, before the definition of the function itself, the data type of the value returned by the function is usually declared along with the input parameters. This declaration is called a prototype declaration. The prototype declaration is required before calling the function when it is called with a back reference, and the prototype declaration may be omitted when the function is called with a back reference. When calling a function, an output variable that receives a value returned by the function, a function name, and a sequence of input parameters may be described in the same format as a normal function. In addition, variables commonly used across multiple functions are called global variables, and it is necessary to describe that.

In FIG. 1, reference numeral 1 denotes a module unit test controller of this embodiment. Module unit test controller 1
Is an interface file processing unit 2 that reads a prototype declaration part of a function to be tested (called a test function) from a specified module file and creates an interface list, and an interactive type as shown in FIG. Display the contents of the interface list in each input / enumeration field of the screen form of and define / edit the referenced global variables etc.
Module definition editor processing unit 3 for creating files
, And read the items of each test function described in the interface file, and using the interactive screen as shown in Fig. 3, based on the value assigned to the input field,
It has a module function automatic execution processing unit 4 for sequentially executing a test function. An external storage device 5 such as a magnetic disk stores an interface file 51 and a module file 52. Reference numeral 6 is a working memory used by the module test control unit, 7 is a keyboard, 71 is a pointing device for designating coordinates corresponding to a display screen, and 8 is a display. The module test control unit 1 can be realized by executing a program by the CPU. In this case, this CPU may control the entire test system.

FIG. 2 shows an example of a display screen displayed by the module definition editor 3.

The operator selects a test function on this screen, causes the interface file processing unit 2 to create an interface list, fills each field based on it, and creates an interface file 51 in the module definition editor processing unit 3. Let In the figure, each frame is a field for displaying candidates, and the downward arrow on the right side thereof is a switch for pulling down display. By specifying this arrow by the operator,
You can display other candidates that are not currently displayed in the field.

In FIG. 2, reference numeral 9 denotes a module file selection field, and the operator selects the source file name of the module to be tested. Reference numeral 10 denotes a test function name selection field for selecting a test function name to be tested. Reference numeral 11 denotes a variable name input field. After reading the source file, the variable name described in the field is displayed, but it can be changed. A variable type selection field 12 lists the types of variable types declared in the include file and selects from them. An include file is an independent file that is incorporated as a part of a module file, and is commonly used by each module, such as a variable type declaration. A parameter number display field 13 indicates the order of parameters passed as arguments. 14 indicates a parameter addition field, and 5
It is for setting the parameters that cannot be displayed directly on the screen in the test function with more than one parameter. A global variable input field 15 is used to set the name of the global variable referenced inside the test function. 16 is a module file read button,
When the operator selects this, the interface file processing unit 2 reads the selected module file and creates an interface list. Reference numeral 17 denotes an interface file save button, which saves all the settings in the interface file 5.

The interface file created in this way contains information relating to the addresses of parameters and functions necessary for executing the test function,
Based on that, the module function automatic execution processing unit 4
Executes the specified test function. The module definition editor processing unit 3 and the module function automatic execution processing unit 4 are
The process may be performed continuously, or each process may be independent and the operator may specify each execution to perform the process independently.

FIG. 3 shows an example of a display screen when the function is executed by the module function automatic execution processing section.

In FIG. 3, reference numeral 18 denotes an interface file selection field in which the operator selects an interface file associated with the function to be tested. Reference numeral 19 denotes a function name selection field for selecting a function to be tested. Reference numeral 20 denotes a parameter value input field for inputting a parameter variable value or an immediate value. The parameter value input field 20 is displayed in a format in which the names of up to four parameters are listed, and the operator inputs the values for the variables of the listed names. 21 indicates a parameter selection field,
Input the fifth or more parameters. A return value display field 22 displays the value of the return value.
Reference numeral 23 denotes a return value content display field, which displays the content of the area referred to by the return value. Reference numeral 24 denotes a global variable selection field for selecting a global variable referred to by the test function. A variable value display field 25 displays the value of the selected global variable. Reference numeral 26 is an execute button for executing the test function, and 27 is an end button.

As for the contents of the above fields, except for variables, parameters, and buttons, the values registered in the interface file 51 created by the module definition editor processing unit 3 are displayed as candidates, and the operators are displayed. Will choose the desired one from them.

As described above, the operator can interactively specify information necessary for execution, such as the function to be tested and the parameter of the function. For this reason,
It is possible to save the trouble of creating a test program for calling a test function for each test function.

The interface between the operator and the test system has been described above. Next, the procedure of each process in the module test control unit 1 will be described.

FIG. 4 is a flow chart showing the processing procedure of the interface file creation processing section.

In this embodiment, when the execution files (objects, libraries, etc.) of the module to be tested are linked, the map file created there is created.
Need a file. The map file is a file in which the state of linked files is recorded, and the names and addresses of linked files, the names and addresses of functions to be linked are recorded.

First, in step 4S1, an interface file (hereinafter referred to as DE
Load the #typedef type declaration for variables prepared in FAULT.ITF) into the working memory 6 in FIG. After that, the reading of the file, the editing of the interface file, etc. are performed in the working memory 6. DEFAULT.ITF has section items as shown in Fig. 5, and item 5-1 has C
It includes the ones defined in the include files provided for language development, and each definition word specifies the passing type (VALue: immediate value, OFFset: offset value, SEGment: segment value) and size of the stack reference. Has been done.

In step 4S2, the specified module file and the map file created at the time of linking are read. If no file is specified, read all module files and map files in the current directory.

In step 4S3, the unique include file referenced by the module file is read.

In step 4S4, the module file name to be tested is indicated by [$$ Module
Register as the item name of the [_Section] item.

At step 4S5, the #typedef declaration statement indicating the variable type defined in the include file is fetched, and at step 4S6, the fetched declaration statement is [$$$] shown in item 5-3 of FIG. Include_Section] item.

In step 4S7, it is determined whether or not there is a keyword for determining the prototype declaration statement. This keyword is explicitly described in the module file in advance, but there is a possibility that it will not be present. Therefore, there is a process after step S10 as a process therefor. If there is a keyword as a result of the determination, step 4S8
At, take out the prototype declaration statement that follows.

In step 4S9, the extracted prototype declaration statement is used to select [$$ Interface_] of item 5-4 in FIG.
Create an interface list structure, as shown in Section. At this time, the test function of the same name in the map file is searched, and the address of the test function is added to the structure. One interface list contains pointers to the next list to create a relational list. This process is repeated as long as the keyword can be found.

If the keyword cannot be found,
In step S10, the read button of the read file is returned to the beginning in order to take out the prototype declaration statement without keywords. In step S11, it is determined whether the file has ended. If the result of determination is that it is not the end, in step S12 a prototype declaration statement without keywords is searched for in the test function. Step 4
In S13, it is judged whether or not the test function is found. If found, the prototype declaration statement is taken out in Step 4S14. At step 4S15, an interface list structure as shown in [$$ Interface_Section] of item 5-4 in FIG. 5 is created from the extracted prototype declaration statement.

If it is not found as a result of the judgment, in step 4S16, the global variable name and address described in the map file are added to [$$ Global_Section] shown in item 5-5 of FIG. The process in the interface / file processing unit 2 ends.

As described above, in the interface file 51, the names and addresses of functions and variables that are externally connected from the module file to be tested are registered.

FIG. 6 is a flow chart showing the processing procedure of the module definition editor processing unit 3. This is an event-driven process in which the process is distributed by issuing an event in accordance with the procedure operated by the user according to the screen of FIG.

If the rightmost scroll button of the module selection field 9 in FIG. 2 is pressed, step 6S
In 1, the module file names to be tested are listed in a pull-down format. In step 6S2, one file name selected from the listed files is acquired and stored in the working memory 6 as a module file variable. The variable data assigned to each field is registered as a new item in each section of the interface file created by the interface file creation processing unit at the saving stage.

Module file read button 16
When is pressed, the selected module file is read into the working memory 6 in step S14. At this time, if the interface file already exists, the interface file is read, and if it does not exist, the interface file creation processing unit 2 is used to read the interface file from the read file in step 6S15. Create a list. In step S16, the contents of the first test function in the interface list are assigned to each field and displayed. This series of processing is a selection means when there are multiple module files. When only one module file exists, module file reading is automatically executed and each item for the first test function is displayed. To be done.

The following is the processing for changing, adding, or modifying the items in the interface list.

In the function name selection field 10, if the rightmost scroll button is pressed, the function names to be tested are listed in a pull-down format in step 6S3. In step 6S4, among the listed functions,
The selected function name is acquired and stored in the working memory 6 as a function name variable. At this time, if another function different from the previous one is selected, each field value of the function is converted into the interface list format and stored in the working memory 6. In step 6S5, the section item with the matching function name is acquired from the interface list on the working memory 6 based on the function name. In step 6S6, [$$ Interface_
The items described in [Section] are assigned to the item enumeration variables of each field and displayed.

In the variable name input field 11, the variable name input and changed by the user is acquired in step 6S7. The variable name entered here is reflected in the parameter name of the interface list.

In the variable type selection field 12, if the rightmost scroll button is pressed, step 6
At S8, item 5 of the interface file 51
The #typedef declaration statements shown in 1, 5-3 are listed in a pull-down format. In step 6S9, the selected variable type is acquired, paired with the parameter, and stored in the working memory 6 as a type type variable or a return value variable.

In the parameter number display field 13,
In step 6S10, the parameter delivery order is displayed in ascending order. The first to fourth parameters can be displayed at one time, but from the fifth parameter, the parameter setting field 14 is used to enumerate the parameter settings in the selected parameter order in step 6S11. Step 6
In S12, the selected delivery number is acquired, the same processing as the variable name input field and the variable type selection field is executed, and the fifth and subsequent parameters are set.

In the global variable input field 15,
In step 6S13, the global variable name referred to in the test function is input. In step 6S9, the selected global variable type is acquired and the variable name and variable type type pair is stored in the working memory 6. If multiple global variables are referenced, once the name and type have been determined, use the scroll button on the far right to display the next input field and make a new entry. Do this for all referenced global variables. The processing up to this point is performed in the same operation procedure for all the functions to be tested in the module file.

Next, with the interface file save button 17, the data of each test function saved in the working memory 6 in step 6S16 is saved as an interface file.
The file is converted into the list format, and the module file name is saved in the external storage device 5 shown as an interface file with a name changed to ".ITF".

By the above procedure, the interface file of the module file containing the test function is created.

FIG. 7 is a flow chart showing the processing procedure of the module function automatic execution processing section. This is an event-driven process in which the process is distributed by issuing an event in accordance with a user's operation procedure.

In the interface file selection field 18 of FIG. 3, if the scroll button at the right end is pressed, the interface files created by the module definition editor are listed in a pull-down format in step 7S1. In step 7S2, the interface file name selected by the user is acquired. In step 7S3, the interface file is read into the working memory 6 and [$$ Interf
The name of the test function registered in [ace_Section] is an enumeration item of the function name selection field 19.

When the scroll button at the right end is pressed, the test function names set in step 7S3 are listed in pulldown format in step 7S4. In step 7S5, the test function name selected from the listed function names is acquired. At step 7S6, [$$ Interface_Se is selected from the interface list corresponding to the test function.
[ction] item, the input parameter names from 1 to 4 among them are displayed, and the parameter names after the fifth are added to the enumerated items of the parameter selection field 21.

In step S7, the value of the parameter is entered in the input value field 20. The entered value depends on the parameter type of the interface list,
Whether it is an address reference or an immediate value is determined. In the parameter selection field 21 and the subsequent parameter value input field 20, the fifth and subsequent parameter names are listed in step 7S8, and the parameter values are sequentially input in step 7S9. As a result, the input operation can be performed for the fifth and subsequent parameters.

In the global variable selection field 24,
In step 7S12, the global variable names registered in items 5-5 of the interface file are listed. In the variable value display field 25, step S13
The variable name selected in step S14 is acquired, and the value before being changed is set in step S14. This field accepts a value input before the function is executed, and displays the value of the variable changed after execution. The parameter input of the test function is completed by the processing so far.

Next, the execute button 26 is pressed, and the test function is executed in step S16. Details are shown in FIG.

In step S16-1, the set parameter value and global variable value are acquired. In step S16-2, the work area for the parameter variable is secured in the work memory 6. In step S16-3, the contents of the section item described in the interface file are fetched from the test function name into the working memory 6. The test function is executed according to the parameter type and function address of this section item.

In step S16-4, it is determined whether there is a global variable referred to in the test function. If there is a reference as a result of the determination, the variable value input in the above process is set in step 7S16-5.

In step S16-6, it is determined whether the parameter transfer is completed. If the result of the determination is that it is not the end, in step 7S16-7, all the parameter types passed to the test function are acquired from the read interface file. Step 7 S1
At 6-8, it is determined whether the parameter is a reference between segments. If the result of determination is that it is a segment reference, the value of the DATA segment assigned to the working memory 6 is pushed to the stack in step S16-9. If it is not a segment reference, it is determined in step 7S16-10 whether it is an address reference. If the result of determination is that it is an address reference, the offset value of the parameter is pushed to the stack in step S16-11. If it is not an address reference, the immediate value of the parameter is pushed to the stack in step S16-12.

The above processing is performed while the parameters are continuously passed, and if the determination is made in step 7S16-6 and the delivery is completed, the process proceeds to step 7S16-13 from the address value corresponding to the function name of the interface file. , The CODE segment of the test function and the call address of the test function are acquired, and step 7S16-14
At, execute the test function. The result of the processing is set in the return value and the field item for displaying the global variable in step 7S16-15.

The details of step S16 are as described above.

At step S10, the value of the return value is displayed. In step S11, if the return value is the address reference value, the contents of the referenced area are displayed. Also,
Regarding the result of changing the global variable, the global variable is selected in steps 7S12 and 13 and the value of the selected global variable is displayed in step 7S15 as in the input procedure. With the above processing, it is possible to perform a test for each function to be tested.

As described above, in the test system of this embodiment, the interface file corresponding to the module file is prepared to provide a unified operation environment for any module and execute the module function alone. Enables testing. The operator can verify the module to be tested by observing the unified screen display according to the unified format procedure regardless of the contents of the module. Therefore, it is not necessary to create a test program for each module, and the module test can be performed efficiently.

Further, since the operator can carry out the test interactively while referring to the menu screen, it is possible to easily change the value of the parameter and the function to be tested, and perform the test efficiently. You can

The test system can be provided in the same computer system as the program development environment. Therefore, it is possible to test the module in less time after the module development.

[0060]

[Other Embodiments] In the present embodiment, a function call mechanism is provided in the module function automatic execution processing unit 4, but by switching this mechanism to the command interpreter,
It is possible to provide a unit test environment for a command utility that you have created or a command utility that does not have a source file and has commercially available parameter inputs.

Although the present embodiment has been described with respect to a program created in C language, it is a common practice to modularize it in subroutine units even if it is written in another language. In such a case, information about the names and addresses of variables and subroutines for connecting the module files, that is, the interface information between the program module that is the test mode and the program that uses it, is used to set appropriate values as parameters. Then, it can be easily understood that the test system can be configured similarly to the present embodiment by calling the test target program.

The present invention may be applied to a system composed of a plurality of devices or an apparatus composed of one device. Further, it goes without saying that the present invention can be applied to the case where it is achieved by supplying a program to a system or an apparatus.

[0063]

As described above, according to the module test method and the apparatus and system using the same according to the present invention, it is possible to perform a unified module unit test in the development of a program and improve the development efficiency. Produce an effect.

[0064]

[Brief description of drawings]

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

FIG. 2 is a schematic diagram of a display screen of a dialog type module definition editor.

FIG. 3 is a schematic diagram of a display screen by a module function automatic execution editor.

FIG. 4 is a flowchart of an interface file creation processing unit.

FIG. 5 is a format of an interface file.

FIG. 6 is a flowchart of a module definition editor processing unit.

FIG. 7 is a flowchart of a module function automatic execution processing unit.

FIG. 8 is a flowchart of a module function automatic execution processing unit.

[Explanation of symbols]

 1 module unit test control unit 2 interface file creation processing unit 3 dialog type module definition editor processing unit 4 module function automatic execution processing unit 5 interface file (external storage device) 6 working memory 7 keyboard 8 display 52 module file (external storage Equipment) 71 pointing device

Claims (6)

[Claims] 1. A method for testing a program module in an information processing system having a display, comprising a reading step of reading interface information described in a program to be tested, and setting data based on the interface information read by the reading step. A display step of displaying a screen to be displayed on the display, an input step of inputting data according to the screen displayed by the display step, and the test target based on the data input by the input step and the interface information. And a step of executing a program. 2. The module test method according to claim 1, wherein the display step displays data to be set in a menu format, and the input step inputs data corresponding to the menu. 3. The interface information includes a name of the program to be tested and input / output parameters of the program.
Module test method described. 4. A module test device for testing a program for each module, wherein the reading means reads interface information described in a program to be tested, and data is set based on the interface information read by the reading means. Display means for displaying a screen on the display, input means for inputting data according to the screen displayed by the display means, and the test target program based on the data input by the input means and the interface information A module test device comprising: 5. The module test apparatus according to claim 4, wherein the display unit displays the data to be set in a menu format, and the input unit inputs the data corresponding to the menu. 6. The module test apparatus according to claim 4, wherein the interface information includes a name of the program to be tested and input / output parameters of the program.