JP2003296139A - Stub forming device and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prepare a stub function reliable in terms of matching property to a processing program including an object for inspection. <P>SOLUTION: In a server 90, an out-of-field program having a function which is required in a source program described therein is read as a file to be stubbed to form a stub file. A non-delete part recognizing block 101 recognizes a non- delete part necessary for compile link. Then, a function recognizing block 102 and a preprocessor command recognizing block 103 recognize the description range of the function including the case having a preprocessor command described therein, thereby, a substantial processing description such as execution line in the function is deleted by an unnecessary part deleting block 105. A form recognizing block 105 recognizes the form of the function to judge the presence of a return value, and a declaration and return adding block 106 adds a variable declaration and return command for the return value thereto. <P>COPYRIGHT: (C)2004,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a test script-based integration test.

[0002]

2. Description of the Related Art In recent years, many computer systems have been adopted in vehicles such as automobiles, and electronic control devices equipped with software have been arranged everywhere in the vehicles. Therefore, reduction of man-hours for software development has become an important issue today. In particular, in the control software installed in the vehicle-mounted computer system, the software has to be changed by changing the parts and specifications of the vehicle.

Therefore, object-oriented design has become mainstream in recent program development. One of them is a method of paying attention to vehicle parts and their functions and creating a program for each unit. This is because the reusability of the program is improved. In this specification, a program for each component or each function will be referred to as a “component program”.

On the other hand, in the inspection of such a program,
In general, individual inspections of individual component programs are performed, and then combined inspection in which component programs are combined is performed.
In the component inspection, the individual operations of the component program are inspected, whereas in the combined inspection, whether the component programs are called in the order specified in the inspection specifications or the operation results obtained by inputting the input data are The main inspection is whether the output data is the same as the prepared output data.

[0005] And, such a joint inspection is shown in FIG.
As shown in (a), the driver 2 is made to correspond to the inspection target 220 in the source program in which the component programs are combined.
It is conceivable that 10 is prepared and performed. by this,
With the driver 210, the inspection target 220 can be executed and inspected by an execution history recording device called a simulator.

However, in this case, it is necessary to individually prepare the driver 210 for the inspection target 220, and
It is necessary to compile and link in units of the driver 210 and the inspection target 220. In particular, in the case of a large-scale program for vehicle control, since the inspection target 220 exists in the order of several thousand, preparation of the driver 210 corresponding to the inspection target 220, or inspection target 220 and driver 21.
It takes a lot of time to compile and link with 0 set.

As a method for solving this, FIG.
As shown in (b), it is conceivable that the entire source program 81 is executed by the execution history recording device and the inspection target 81a is specified by the inspection script 82 in which the inspection information is described. In this case, the inspection script 8 for each inspection target 81a
However, if the driver 41 is compiled and linked together with the source program 81, the execution history recording device can inspect a plurality of inspection targets 81a by simply changing the inspection script 82.
In other words, even if the inspection target 81a is increased,
Since no link occurs, the inspection man-hour can be reduced.

[0008]

At this time, FIG.
As shown in (a), consider the case where the function B called from the function A is used as the check start function, that is, the case where the function B or lower called from the function A becomes the check target 81a.

In such a case, the function B of the object 2
The function C called from the source program 81 is different from the source program 81, for example, a platform (hereinafter referred to as “PF”).
May exist in a program outside the field called. During the development, the function C called from the inspection target 81a of the source program 81 may not exist.

Therefore, it is necessary to prepare a dummy function C called a stub in order to perform the joint inspection. That is, it is necessary to prepare the stub function necessary for the source program 81 in order to perform the above-mentioned connection inspection. At this time, it is possible to create a stub based on the source program 81.
When 1 is a control program for a vehicle, there is a possibility that a part to be executed and a part not to be executed may be included depending on the destination. A so-called compiler may be used for conditional compilation.

Therefore, in the case of automatically creating the source program 81, the stub creating process becomes complicated, and as a result, the reliability with respect to the consistency with the source program 81 becomes low. . The present invention is
The purpose is to create a stub function that is highly reliable in terms of consistency with respect to a processing program including an inspection target.

[0012]

Means for Solving the Problems and Effects of the Invention A stub creation apparatus of the present invention executes a processing program subdivided for each unit function, and a history of processing execution based on an inspection script in which inspection information is described. To record, create a stub function required to execute the processing program.

Here, in particular, the present invention is characterized by including source acquisition means and stub creation means. The source acquisition means acquires the source description of the stubbing target program including the function called from the processing program.
The stubification target program is an out-of-field program such as PF prepared separately from the processing program. Then, the stub creation means creates a stub function by deleting the substantial process description based on the acquired source description.

This technical idea is based on the premise that there is a stub object file whose consistency is confirmed at least in terms of function calls in the processing program including the object to be inspected. In other words, especially in the process of developing a program related to vehicle control, the processing content itself may not be appropriate from the aspect of reusing the program, but there are out-of-field programs in which the function description necessary for the processing program has been made. I often do it. And, such a program outside the field is guaranteed to be completely consistent with the processing program developed in the past. Therefore, if there is no change in the function call part of the processing program under development, the stub function can be created using the existing program outside the field, and the consistency is guaranteed.

In the present invention, paying attention to such a point, the out-of-field program whose consistency is guaranteed is set as the stubization target program, and the substantial processing description is deleted,
Create a stub function. As a result, it is possible to create a highly reliable stub function in terms of consistency with respect to the processing program including the inspection target.

It is considered that the stub creating means deletes the substantial process description by recognizing, as a non-deleted part, a part necessary for compiling and linking the program to be stubbed (claim 2). ). By recognizing such a non-deleted portion, automation of stub creation is promoted. At this time, the non-deleted portion may include a comment statement not related to compile / link (claim 3). This is because the readability after creation is improved.

By the way, specifically, the stub creating means is
It is conceivable to delete the substantial process description by recognizing the description range of the function (claim 4). This is because it is necessary to surely delete only the substantive processing description in the function. At this time, the stub creation means is
It is desirable to recognize the description range of the function by recognizing the preprocessor instruction (claim 5). This is because, depending on the preprocessor instruction, the part that is selectively compiled may be part of the function. By doing this, it is possible to create a stub function that also supports conditional compilation of the processing program.

Further, when the function is macro-defined, the stub creating means is better to recognize the description range of the function including the macro definition part (claim 6). This is because in a macro-defined function, the actual processing is described in the macro definition part. By doing this, it is possible to automatically create a stub function from a macro-defined function.

Note that the stub function is a dummy function that does not perform substantial processing, but in terms of consistency of function calls with the processing program, it is necessary to prepare a dummy return value. Therefore, the stub creating means recognizes the type of the function based on the function description, determines whether there is a return value, and if there is a return value, declares a variable for the return value and returns an instruction. It is preferable that the stub function is created by adding. This further facilitates the automatic creation of the stub function. At this time, when the function is macro-defined, it is conceivable to add a variable declaration and a return instruction using the macro definition (claim 8). By thus adding the variable declaration and the return instruction using the macro definition, the return value can be appropriately described for each of the macro-defined functions.

By the way, the return value of a function depends on the type of the function, but the type of the function may be defined by an alias. Therefore, it is desirable that the stub creating means can determine whether or not the function has a return value by using the definition information indicating that the function type is defined by an alias (claim 9). By doing so, even if the function type is defined by an alias, it is possible to determine whether or not there is a return value, and it is possible to appropriately add a variable declaration and a return instruction. Since the function type alias definition is written in the source file or the header file by a "typedef" command or the like in the C language, it is conceivable to analyze them as definition information. At this time, it is conceivable that the definition information describes the type of a function having no return value (claim 10).
That is, in order to determine whether or not there is a return value, it is sufficient to know either the type with a return value or the type without a return value. And the definition of a type without a return value is generally smaller than the definition of a type with a return value. Therefore, in this way, the amount of definition information is reduced.

Incidentally, the inspection start function is usually judged based on the inspection script, and the history of processing execution for the functions under the inspection start function is recorded. At this time, the inspection start function may be called from the stub function. Therefore, the stub creation means uses the test start function information created based on the test script and indicating the call source of the test start function and the test start function. If the stub function is the call source, the test A stub function may be created by adding an argument declaration and a call instruction to the start function (claim 11). This makes it possible to automate the process from the stub function to the start of inspection.

Although the invention of the stub creating apparatus has been described above, the function of such a stub creating apparatus can be realized as a program activated by a computer. In this sense, the present invention can be realized as a program that causes a computer to function as each unit of the stub creating apparatus described above (claim 12).

In the case of such a program, for example, F
It can be used by recording it on a computer-readable recording medium such as D, MO, CD-ROM, DVD-ROM, HD, etc., and by loading it into a computer and activating it as necessary. In addition, ROM and backup RAM
The program may be recorded as a computer-readable recording medium, and the ROM or the backup RAM may be incorporated into a computer for use.

[0024]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is an explanatory diagram showing a schematic configuration of the execution history recording system of the present embodiment. The execution history recording system includes an execution history recording device 10 and a server 90. It should be noted that although the system is configured here to include the execution history recording device 10 and the server 90, it may be implemented as a single computer system.
That is, it may be realized as a system having both the functions of the execution history recording device 10 and the server 90.

The execution history recording device 10 includes an apparatus main body 11,
This is a so-called computer system including a monitor 12 as display means and a keyboard 13 as input means. On the other hand, the server 90 is also a computer system, and includes a device body 91 and a monitor 92 as a display unit.

A large-capacity hard disk device 80 is connected to the device main body 91.
0 is a source program 81, an inspection script 82,
And the stub 83 is recorded. Source program 8
1 and the inspection script 82 are created and stored by the user. The stub 83 is installed on the server 9 before the inspection.
It is automatically created by 0. The execution history recording device 10
The above three pieces of information are read from the server 90, and the execution history is recorded based on these three pieces of information.

The source program 81 is composed of a component program created for each component or for each function, and is composed of a plurality of files. Inspection script 8
Reference numeral 2 describes the inspection information and is created as a text file. This inspection script 82 is
Created for each inspection target.

Specifically, in the inspection script 82, the name of the inspection start function and the name of the parent function that calls the inspection start function are described as a set. by this,
Check start function when called from a specific parent function The following functions are specified as the check target. Further, the inspection script 82 has a variable setting description. That is, the name of the variable to be inspected and the input data to the variable are described. Furthermore, output data that is a solution corresponding to the input data is described in advance.

The stub 83 is a dummy function group that is called from a function below the inspection start function. This stub 83
Are automatically created by the server 90 as described above.
In this embodiment, the stub 8 by the server 90 is used.
It has a feature in the creation of 3.

Therefore, the creation of the stub 83 by the server 90 will be described in detail below. FIG. 2 is a functional block diagram of the server 90. The server 90 reads a stub object file, an environment file, and inspection start information, and outputs a stub file and a result log. The stub file output here corresponds to the stub 83 shown in FIG.

The stubbing target file is a program outside the field prepared separately from the source program 81 and includes the above-mentioned PF and the like. The technical idea here is that a stub function is created using this out-of-field program, assuming that there is an out-of-field program whose consistency is confirmed at least in terms of function calls with respect to the source program 81 under development. Is to do. The following description will be continued assuming that the stubbing target file is described in C language.

In the environment file, as shown in FIG. 3A, information for recognizing the function type defined by the user by an alias is described. The functional recognition here is
It is the recognition whether the stub function to be created has a return value. Therefore, the return type, that is, the function type having the same value as the void type is described in the environment file. Figure 3
In (a), "NOTmodori", "VIOD",
The type name "HANDLER" is shown as an alias for the void type.

The inspection start function information is created by the operator or automatically from the inspection script 82 shown in FIG. As the inspection start function information, as shown in FIG. 3B, the name of the definition function that is the caller of the inspection start function, the name of the inspection start function, and the argument are described. Such inspection start function information is necessary because the inspection start function may be called from the stub function. For example, as shown in FIG. 16B, the function A called from the stub function C in the PF is the check start function.

The function of the server 90 is as shown in FIG.
Non-Deleted Part Recognition Block 101, Function Recognition Block 10
2, a preprocessor instruction recognition block 103, a type recognition block 104, an unnecessary portion deletion block 105, a declaration / return addition block 106, and a check start function creation block 107.

The non-deleted portion recognition block 101 recognizes the non-deleted portion of the stubbing target file description. The non-deleted part is a part required for compile and link, and the non-deleted part includes a preprocessor instruction, an external variable declaration, a function prototype declaration, a continuation code "\", and the like. In addition, comment sentences that are not directly required for compiling and linking are also treated as non-deleted parts to improve readability.

The function recognition block 102 recognizes a function for deleting the execution line of the function. Here, the description form "symbol () {" in the file to be stubbed is searched, and the symbol immediately before the parenthesis "(" is recognized as the function name. }] Is the range of the function.

Preprocessor instruction recognition block 103
Recognizes a preprocessor instruction and corrects the function range. As described above, the function recognition block 102 recognizes the description of "symbol () {" as a function. However, even if there is no symbol, there is a part that is in the function range due to the preprocessor instruction. Therefore, by recognizing the preprocessor instruction, all the function descriptions selectively compiled by the conditional compilation are recognized as the function range.

The type recognition block 104 recognizes the type of the function. Usually, what is written before a symbol is the function type. However, since it may be defined by another name by the user, it is determined whether or not there is a return value by referring to the environment file described above. This is because the stub processing differs depending on whether there is a return value or not.

The unnecessary portion deletion block 105 includes a function recognition block 102 and a preprocessor instruction recognition block 10.
Based on the function range recognized in 3, the execution line of the function, that is, the substantial processing description is deleted. The execution line of the function includes declaration statements of local variables and return instructions.

The declaration / return addition block 106 declares a variable for the return value for the function judged to have a return value by the type recognition block 104, and adds a return instruction. The variable declaration for the return value is declared in each function type. The check start function creation block 107 adds an argument declaration and a call instruction for the function call when the function called from the stub function is the check start function, based on the check start function information described above.

Here, the function of each of the blocks 101 to 107 described above will be specifically described by exemplifying the description of the stubbing target file. (Description example 1) In FIG. 4, file1. The description of c is shown. Note that the numerical values at the left end are assigned for convenience of explanation, and the same applies to the subsequent drawings.

First, the non-deleted part recognition block 101 reads such a stubbing target file and recognizes the non-deleted part. The non-deleted portion that is actually recognized is shown by underlining in FIG. Since these are descriptions required for compiling and linking, they are first recognized as non-deleted parts.

Then, the function recognition block 102 and the preprocessor instruction recognition block 103 recognize the range of the function. This is as shown by underlining in FIG. Execution line 1 and execution line 2 are selectively compiled for the function f1 by the preprocessor instructions in lines 5, 9, and 13. Therefore, here, the preprocessor instruction recognition block 103 recognizes that the range of the function f1 is up to 12 lines. The range of the function f2 is 14 to 17 lines, the range of the function f3 is 18 to 21 lines, and the function f
The range of 4 is recognized as 22 to 25 lines.

The type recognition block 104 recognizes the types of the functions f1 to f4. For the function f1, "i
As the "nt" type, the function f2 is recognized as the "char" type, the function f3 is recognized as the "NOTmodori" type, and the function f4 is recognized as the "void" type. Then, by referring to the environment file (see FIG. 3A), the type “NOTmodori” of the function f3
Is judged to have no return value equivalent to the void type.

Next, the unnecessary portion deletion block 105 deletes the unnecessary portion. The unnecessary portion deleted at this time is shown by underlining in FIG. 7. Here, execution line 1 (7 lines),
Execution line 2 (11 lines), execution line 3 (16 lines), execution line 4
(20 lines) and execution line 5 (24 lines) are deleted as unnecessary parts.

Declaration / return addition block 10
6 adds a variable declaration for a return value and a return instruction to the functions f1 and f2 having a return value. This is as shown by underlining in FIG. In FIG. 8, the function f1 (4
In the n1 line immediately before the line), the variable "f1_r" for the return value
"et" is declared as an int type, and the return instruction "r
"turn f1_ret;" is added. Also,
In the n2 line immediately before the function f2 (14th line), the variable “f2_ret” for the return value is declared in the char type, and the return instruction “return f2_ret;” is added to the 16th line.

Further, according to the inspection start function information shown in FIG. 3B, since the function call_func1 called from the definition function f3 is the inspection start function, the inspection start function creation block 107 calls the function call. Argument declarations and call instructions for are added. This is as shown by underlining in FIG. In FIG. 9, the argument declaration is added to the 20th line, and the function call_func is added to the n3th line.
1 is being called.

(Description Example 2) Next, a description of a macro-defined function will be described as an example. In FIG. 10, as an example of the stubbing target file including the macro-defined function, f
ile2. The description of c is shown.

First, the non-deleted portion recognition block 101 reads such a stubbing target file and recognizes the non-deleted portion. The non-deleted part that is actually recognized is shown in FIG.
Is underlined. Since these are descriptions required for compiling and linking, they are first recognized as non-deleted parts. Further, here, in order to improve readability, the comment sentence is recognized as a non-deleted portion (lines 5 and 6).

Then, the function recognition block 102 and the preprocessor instruction recognition block 103 recognize the range of the function. This is as shown by underlining in FIG. Here, in particular, the function range is recognized including the macro definition. Then, using the macro definition of lines 2-10, 1
Functions in lines 5 and 16 are recognized. Specifically, the function "MA
CRO (1) "is recognized as a function" func_C1 ", and function" MACRO (2) "is recognized as a function" func_C2 ".

The type recognition block 104 recognizes the types of the functions f1, func_C1, func_C2. The function f1 is of type “int” and the function fu
nc_C1 and func_C2 are recognized as "long" type. Next, the unnecessary portion deletion block 105
However, delete unnecessary parts. The unnecessary portion deleted at this time is shown by underlining in FIG. Here, "in
t i; "(line 5), execution line 1 (line 7)," retur
n 0; ”(line 8) and execution line 2 (line 13) are deleted as unnecessary parts.

Declaration / return addition block 10
6 is a function f1, func_C1, fun with a return value
A variable declaration for a return value and a return instruction are added to c_C2. This is as shown by underlining in FIG. In FIG. 14, a return instruction matching the macro definition is added to the n1 line in the macro definition. Correspondingly, the variables "func_C1_ret" and "func_C2_ret" for the return value are declared in the long type in the lines n3 and n4 immediately before the macro function (lines 15 and 16). Also, in the n2 line immediately before the function f1 (line 11), the variable “f1_ret” for the return value is declared in the int type, and the return instruction “returnf1_re” is written in the 13th line.
"t;" is added.

Next, the effect of the server 90 of this embodiment will be described. In the present embodiment, in the server 90, a program outside the field in which the function description required by the source program 81 is written is read as a file to be stubbed, and the non-deleted part recognition block 101 recognizes the non-deleted part necessary for compile / link. To do. Next, the function recognition block 102 and the preprocessor instruction recognition block 103
By this, the description range of the function is recognized, including the case where the preprocessor instruction is described, so that the substantial processing description such as the execution line in the function is deleted by the unnecessary part deletion block 1
Deleted by 05. Also, the type recognition block 104
Recognizes the function type, determines whether there is a return value, and
The add return block 106 adds variable declarations and return instructions for the return value.

That is, particularly in the process of developing software related to vehicle control, there are many out-of-field programs in which the function description necessary for the source program 81 is described from the viewpoint of reuse. Therefore, if there is no change in the function call part of the source program 81, the stub function is created by using the program outside the field as the file to be stubbed and mainly deleting the execution line in the function.

As a result, for the source program 81,
It is possible to create a stub function that is highly reliable in terms of consistency. At this time, the non-deleted part recognition block 101 recognizes a part necessary for compiling and linking the program to be stubbed as a non-deleted part (see FIGS. 5 and 11), which contributes to automation of stub creation. Furthermore, since the comment text is also treated as a non-deleted portion, the readability of the created stub file is improved.

Further, since the function recognition block 102 recognizes the function description range, it is possible to surely delete only the substantial process description in the function. Further, the preprocessor instruction recognition block 103 recognizes the preprocessor instruction and recognizes the description range of the function (see FIG. 6). This makes it possible to create a stub file corresponding to the conditional compilation of the source program 81. If the function is defined as a macro, the description range of the function is recognized, including the macro definition part (see FIG. 12).
This allows you to automatically create a stub file from a macro-defined function.

Furthermore, the type recognition block 104 recognizes the type of the function and determines whether or not there is a return value. At this time, since the environment file indicating the function type defined by the alias is referred to, even if the function type is defined by the alias, it is possible to determine whether or not there is a return value. Moreover, since the type of a function that does not have a return value is described in the environment file, the amount of information in the environment file is reduced.

Declaration / return addition block 10
6 adds a variable declaration for the return value and a return instruction based on the judgment of the type recognition block 104 (see FIG. 8). This further facilitates the automatic creation of stub functions. Then, when the function is macro-defined, a variable declaration and a return instruction are added using the macro definition (see FIG. 14). Therefore, a return value can be automatically defined for each macro-defined function.

Further, in the present embodiment, the inspection script 82
The inspection start information created from was acquired. The inspection start information indicates the inspection start function and the caller of the inspection start function. Then, when the stub function is the caller, the check start function creation block 107 adds an argument declaration and a call instruction to the check start function to create a stub function (see FIG. 9). This makes it possible to automate the inspection from the stub function.

The blocks 101 to 107 showing the function of the server 90 in this embodiment are "stub creating means".
Further, the non-deleted part recognition block 101 corresponds to “source acquisition means”. It is needless to say that the present invention is not limited to such an embodiment, and can be implemented in various forms without departing from the spirit of the present invention.

[Brief description of drawings]

FIG. 1 is an explanatory diagram showing a configuration of an execution history recording system according to an embodiment.

FIG. 2 is a functional block diagram showing functions of a server.

FIG. 3A is an explanatory diagram illustrating an environment file, and FIG. 3B is an explanatory diagram illustrating inspection start function information.

FIG. 4 is an explanatory diagram showing a stubbing target file.

FIG. 5 is an explanatory diagram showing a non-deleted portion of a stubbing target file.

FIG. 6 is an explanatory diagram showing a function range of a stubbing target file.

FIG. 7 is an explanatory diagram showing unnecessary portions of a stubbing target file.

FIG. 8 is an explanatory diagram showing addition of a return instruction to a file to be stubbed.

FIG. 9 is an explanatory diagram showing addition of a call instruction to a check start function.

FIG. 10 is an explanatory diagram showing another file to be stubbed.

FIG. 11 is an explanatory diagram showing a non-deleted portion of another stubbing target file.

FIG. 12 is an explanatory diagram showing a function range of another stubbing target file.

FIG. 13 is an explanatory diagram showing an unnecessary portion of another stubbing target file.

FIG. 14 is an explanatory diagram showing addition of a return instruction to another stubbing target file.

FIG. 15 is an explanatory diagram showing a method of joint inspection.

FIG. 16 is an explanatory diagram showing a stub function call.

[Explanation of symbols]

10 ... Execution history recording device 11 ... Device body 12 ... Monitor 13 ... Keyboard 41 ... driver 80 ... Hard disk device 81 ... Source program 81a ... inspection target 82 ... Inspection script 83 ... Stub 90 ... server 91 ... Device main body 92 ... Monitor 101 ... Non-deleted part recognition block 102 ... Function recognition block 103 ... Preprocessor instruction recognition block 104 ... Type recognition block 105 ... Unnecessary part deletion block 106 ... Declaration / return additional block 107 ... Inspection start function creation block 210 ... driver 220 ... Inspection target

Claims (12)

[Claims] 1. A stub function required to execute the processing program when executing a processing program subdivided for each unit function and recording a history of processing execution based on an inspection script in which inspection information is described. A source acquisition means for acquiring a source description of a stubbing target program including a function called from the processing program, and a substantial processing description based on the acquired source description. And a stub creating means for creating the stub function by deleting the stub function. 2. The stub creation device according to claim 1, wherein the stub creation means recognizes a portion necessary for compiling and linking the program to be stubbed as a non-deleted portion, thereby performing the substantial processing. A stub creation device characterized by deleting a description. 3. The stub creation device according to claim 2, wherein the non-deleted portion also includes a comment statement not related to compile / link. 4. The stub creating device according to claim 1, wherein the stub creating unit deletes the substantial process description by recognizing a description range of the function. A stub making device. 5. The stub creation device according to claim 4, wherein the stub creation means recognizes a description range of the function by recognizing a preprocessor instruction. 6. The stub creation device according to claim 4 or 5, wherein the stub creation means, when the function is macro-defined, recognizes the description range of the function including the macro definition part. A stub creation device characterized by: 7. The stub creation device according to claim 1, wherein the stub creation means recognizes the type of the function based on the function description and determines whether or not there is a return value. Then, when there is a return value, the stub creating apparatus is characterized in that the stub function is created by adding a variable declaration and a return instruction for the return value. 8. The stub creation device according to claim 7, wherein the stub creation means adds the variable declaration and the return instruction by using the macro definition when the function is macro defined. A stub creation device characterized in that 9. The stub creating device according to claim 7, wherein the stub creating means uses definition information indicating that the type of the function is defined by an alias, and the return value is returned to the function. A stub creation device characterized by being able to determine whether or not there is. 10. The stub creation device according to claim 9, wherein the definition information describes a type of a function having no return value. 11. The stub creation device according to claim 1, wherein the stub creation means indicates a test start function created based on the test script and a caller of the test start function. A stub creation device that uses the inspection start function information and, when the stub function is the caller, adds an argument declaration and a call instruction to the inspection start function to create the stub function. . 12. A program for causing a computer to function as each unit of the stub creating apparatus according to claim 1.