JPH08106404A - Automatic driver generating device for software test - Google Patents

Abstract

PURPOSE: To automatically generate the test driver which can conduct a test continuously without interruption even if a module to be tested becomes abnor mal. CONSTITUTION: The automatic driver generating device for the software test consists of a module interface information input part 1 and a test driver generation part 2, and the test driver generation part 2 is provided with a driver program generation part 2a, a test execution program generation part 2b, and a program composition part 2c to generate the test driver 3 which conducts the test through two separate processes, i.e., an execution process which actually conducts the test and a driver process which confirms the end state of the process conducting the test, thereby automatically generating the test driver which can execute plural test data continuously even if the tested program becomes abnormal during the test.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software test driver automatic generation device, and is suitable for use, for example, in a device for automatically generating a batch type test driver that automatically executes a plurality of test data in succession. It is a thing.

[0002]

2. Description of the Related Art Conventionally, in a normal software module test, a tester creates a test driver for testing a module for each module. Further, since it is necessary to test the test driver itself, it takes a lot of effort to create the test driver.

On the other hand, the idea of automatically generating a test driver has long existed. For example, "Automatic Software Tes
t Drivers (1978, IEEE) ”.

Further, Japanese Patent Laid-Open No. 5-1433 of Japanese Patent Laid-Open
In the "test program generation device" proposed in Japanese Patent Laid-Open No. 93 and the "test program generation method" proposed in Japanese Patent Laid-Open No. 5-19758, the same idea as the above paper is proposed. .

[0005]

However, when the test is actually executed, the program ends abnormally due to an abnormality in the module to be tested, or the program falls into an infinite loop. May occur.

When such an abnormal phenomenon occurs, even if the test execution is performed in batch using a plurality of test data, the automatic test execution will be interrupted once the abnormality occurs. There is.

In the conventional test driver generated by the automatic test driver generation device, no consideration has been given to such a case. Further, the above paper did not mention how to deal with such a case.

Also, in the above-mentioned Japanese Patent Laid-Open No. 5-143393 and Japanese Patent Laid-Open No. 5-19758, it is not possible to deal with the occurrence of an abnormality, so that the module to be tested ends abnormally, If an infinite loop occurs, the test execution will be interrupted and the test work cannot be performed efficiently.

In view of the above-mentioned problems, the present invention automatically provides a test driver capable of continuously performing the test execution without interruption even when an abnormality occurs in the module to be tested during the test. The purpose is to be able to generate.

[0010]

SUMMARY OF THE INVENTION A software test driver automatic generation apparatus according to the present invention includes an interface information input section for inputting interface information of a test target module, and a test for actually executing the test target module. And a test execution program generator that automatically generates a test execution program that
A driver program generation unit that automatically generates a driver program for executing the test execution program generated by the test execution program generation unit as a separate independent process, and a test execution program generation unit generated by the test execution program generation unit. The test execution program is combined with the driver program generated by the driver program generation unit to generate a test driver.

Another feature of the present invention is that
The test execution program generation unit determines a program for reading test data and an infinite loop of the test target module by abnormally ending the test after a certain time has passed from the start of the test. And a program for passing and executing the read test data to the test target module, and a program for outputting the execution result of the test target module. And

Another feature of the present invention is that the driver program generation unit executes a test execution program as another independent process and another test execution program as another independent process. When the program is executed as, the program for checking the end status of the process that executed the test execution program and the above test execution program that has terminated due to some abnormality output the test execution result of the abnormal termination. And a program for executing the above-described processing program on all the test data are generated.

[0013]

Since the software test driver automatic generation apparatus of the present invention comprises the above technical means, it has two processes, an execution process for actually executing the test and a driver process for confirming the end state of the process for executing the test. It becomes possible to generate a test driver with a mechanism to execute the test separately, so that even if an error occurs in the test target program at the time of testing, multiple test data are executed continuously. Will be able to.

[0014]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of a software test driver automatic generation apparatus of the present invention will be described below with reference to the drawings.
FIG. 1 shows an embodiment of the present invention and is a block diagram showing a schematic configuration of an automatic driver generation apparatus of the present embodiment.

As shown in FIG. 1, the software test driver automatic generation apparatus of this embodiment is composed of a module interface information input section 1 and a test driver generation section 2, and is used for a test target program at the time of test execution. The test driver 3 having a mechanism capable of coping with an abnormality can be automatically generated.

The module interface information input section 1 of this embodiment is provided to input the interface information of the module to be tested. For example, the source code in which the module to be tested is mounted is input, the source code is automatically parsed, and the input and output variables to the module to be tested can be analyzed.

The test driver generator 2 has a driver program generator 2a, a test execution program generator 2b, and a program synthesizer 2c, and is adapted to automatically generate the test driver 3.

As shown in the block diagram of FIG. 2, the driver program generator 2a includes a first driver program generator 21, a second driver program generator 22, and a third driver program generator 23. It is composed by.

Further, the test execution program generator 2
b is composed of a reading program generation means 11, an execution program generation means 12, a time limit setting program generation means 13, and an execution result output program generation means 14.

The test driver generation unit 2 of the present embodiment thus configured automatically generates the test driver as follows based on the result input by the module interface information input unit 1. That is, as shown in the flowchart of FIG. 3, when the process starts, first,
When the source code to be tested is supplied in step S1, module interface information analysis is performed in the next step S2.

Hereinafter, the processes of steps S3 to S10 are performed, but the processes of steps S3 to S6 are performed by the test execution program generation unit 2b, and steps S7 to S9 are performed by the driver program generation unit 2a.
The process of step S10 is performed by the program synthesizing unit 2c.

First, in step S3, the reading program generating means 11 generates a program for reading test data. Next, in step S4, the execution program generation means 12 generates a program for executing the test target module.

In the next step S5, the time limit setting program generating means 13 generates a program for abnormal termination after a certain time in order to determine the infinite loop of the module to be tested. As a result, the time limit for the execution of the test target module is set, and the test data read to the test target module is passed and executed. In the next step S6, the execution result output program generation means 14 generates a program for outputting the execution result of the module to be tested.

The test execution program 10 is generated by the processing of these steps S3 to S6. The test execution program 10 is a part of the test driver 3 for actually calling a module to be tested and executing a test, and is a processing program for one test data.

In the next step S7, the first driver program generating means 21 generates a program for executing the test execution program as another independent process.

Further, in step S8, when the second driver program generation means 22 causes the test execution program to be executed as another independent process, the end state of the process executing the test execution program is inspected. The program is generated.

Further, in step S9, when the test execution program has ended due to some abnormality, the third driver program generation means 23 outputs the test execution result of the abnormal end, and A program that causes the program that performs the process of (1) to be executed on all test data is generated. The driver program 20 is generated by these steps S7 to S9. The driver program 20 can execute the test execution program 10 as an independent separate process.

In the next step S10, the program synthesizing unit 2c synthesizes the test execution program 10 generated as described above and the driver program 20 to generate the test driver 3.

In this way, by generating the test driver 3 which causes the process for actually executing the module to be tested to be executed as a separate independent process, the abnormality of the module to be tested during the test execution is dealt with. It becomes possible to automatically generate the test driver 3 which can be performed.

Next, how the test driver 3 automatically generated by the software test driver automatic generation of this embodiment operates will be described. 4 and 5
The flowchart of an example of the test work of the test driver 3 according to the present embodiment is shown in FIG. As described above, the test driver 3 generated by the software test driver automatic generation device according to the present embodiment is the driver program 20.
And a test execution program 10.

First, in step S1, the test execution program 10 and the driver program 20 are linked with the program to be tested, and a test execution file is created.

Next, in step S2, step S1
The test is executed using the executable file created in. When the test is executed, first, the driver program portion is executed in step S3 to create a driver process.

As a result, the driver process and the test execution process are performed in and after step S4, but in FIG. 4 and FIG.
Step S9 shows the driver process, and step S1
0 to step S14 show the test execution process.

As described above, when the driver process is created, the process proceeds to step S4, and the driver process creates a test execution process. Then, in the next step S5, it is determined whether or not the test is executed, and if the test is executed, the process proceeds to step S10.

In step S10, the test data input to the test target program is read, and then the process proceeds to step S11 to execute the test target program.

Next, in step S12, it is judged whether or not an abnormality has occurred, and if the execution of the program under test ends normally, the process proceeds to step S13 to output the result, and then the process proceeds to step S14. To finish.

Further, as a result of the determination in step S12, if an abnormality occurs during the test execution, the test execution process abnormally ends due to an interrupt (segmentation fault or the like) from the operating system.
If the execution of the test target program does not end even after a certain period of time, it is determined to be an infinite loop, and the test execution process also abnormally ends at that time.

The driver process waits until the generated test execution process ends (step S6). Then, in step S7, the abnormal state of the program to be tested is detected by confirming the end state of the test execution process. If an abnormality has occurred, the execution result at the time of abnormality is output in the next step S8.

Next, in step S9, it is determined whether or not all the test data has been executed. If there is the next test data, the process returns to step S4 to newly generate a test execution process, and the next test data Go to execution. If the execution of all the test data has been completed, the driver process itself ends and the test execution ends.

In this way, all the test data are executed when the driver process is completed. At that time, all the test data can be continuously executed even when an abnormality such as an abnormal end or an infinite loop occurs while the module to be tested is being executed with certain test data.

As described above, the software test driver automatic generation apparatus of this embodiment is divided into two processes: a process for actually executing a test and a process for confirming the end state of the process for executing the test. The test driver 3 automatically generated by the software test driver automatic generation apparatus according to the present embodiment has a structure in which a test target program at the time of a test is abnormal. It is possible to run multiple test data.

Next, as a specific example of the present invention, an example in which the sample program of FIG. 6 written in C language is tested will be shown.

As shown in FIG. 6, this program
This is a sample program that may cause abnormalities such as aborts and infinite loops. By inputting the source code of this sample program into the software test driver automatic generation device according to the present embodiment, the module interface information input unit 1 analyzes the source code, and the test driver generation unit 2 tests the test target module. The driver 3 is automatically generated.

By linking the test driver 3 with the sample program of FIG. 6, an execution file for testing is created. Then, in the execution file for the test, in which is the input variable of the program to be tested
A test using the test data is executed by passing a test data description file in which the test data to be input to the t-type variable x and the structTEST type variable t are described as shown in FIG. 7. In this test data description file, three test data are described, and a number for identifying the test data is added to each test data.

As a result of performing the test with the above test data, the test execution result as shown in FIG. 8 is output for each test data. An identification number corresponding to the test data is added to the test execution result.

In the test execution result of FIG. 8, the first and third test results show that the test execution is abnormally terminated by an interrupt called a signal during the test execution, and the number indicating the type of the signal is output. Has been done.

The second test result is the test execution result when no abnormal termination occurs, and the execution result by the module to be tested is output. In this example, although the abnormality has occurred due to the execution of the first test data, it can be seen that the next test data can be continuously executed.

[0048]

As described above, according to the present invention, it is possible to automatically generate a test driver to be created at the time of executing a test, and to test a program composed of a large number of modules or to specify the module specifications. It becomes possible to efficiently perform a test due to a change or the like.

Further, since it becomes possible to automatically generate an advanced test driver having a function of continuously executing a test even when the test is terminated in an abnormal state, the conventional test driver can be used. Compared with the test driver generated by the automatic generation device / method, more efficient test work can be performed.

In particular, a more effective test work can be performed at the time of automatic execution of a test by a batch type test driver which automatically executes a plurality of test data continuously and automatic execution of a degenerate test.

[Brief description of drawings]

FIG. 1 is a block diagram showing an embodiment of a software test driver automatic generation device of the present invention.

FIG. 2 is a block diagram showing a schematic configuration of a test driver generation unit.

FIG. 3 is a flowchart showing a procedure for generating a test driver.

FIG. 4 is a flowchart showing a flow of processing when a test is executed.

FIG. 5 is a flowchart showing the flow of processing when a test is executed.

FIG. 6 is a diagram showing a specific example of a sample program.

FIG. 7 is a diagram showing a specific example of test data.

FIG. 8 is a diagram showing a test execution result.

[Explanation of symbols]

 1 Module Interface Information Input Unit 2 Test Driver Generation Unit 2a Driver Program Generation Unit 2b Test Execution Program Generation Unit 2c Program Synthesis Unit 3 Test Driver 10 Test Execution Program 11 Reading Program Generation Means 12 Execution Program Generation Means 13 Time Limit Setting Program Generation Means 14 Execution Result Output Program Generation Means 20 Driver Program 21 First Driver Program Generation Means 22 Second Driver Program Generation Means 23 Third Driver Program Generation Means

Claims (3)

[Claims] 1. An interface information input section for inputting interface information of a module to be tested, and a test execution for automatically generating a test execution program for actually executing the module to be tested. A program generation unit, a driver program generation unit that automatically generates a driver program for executing the test execution program generated by the test execution program generation unit as a separate process, and the test execution described above. A software test driver automatic system, comprising: a test execution program generated by a program generation unit; and a program synthesis unit that synthesizes a driver program generated by the driver program generation unit to generate a test driver. Living Equipment. 2. The test execution program generation unit includes a program for reading test data and a module to be tested by abnormally ending the test after a lapse of a certain time from the start of the test. The program to judge the infinite loop of, the program to pass the test data read to the module to be tested and execute it, and the program to output the execution result of the module to be tested. An automatic driver generation device for software testing according to claim 1, wherein the automatic driver generation device is for generating. 3. The driver program generation section executes a test execution program as a separate independent process, and a test execution program when the test execution program is executed as an independent separate process. A program for checking the end status of the executed process, and a program for outputting the test execution result of the abnormal termination when the above test execution program has terminated due to some abnormality, and the above processing 2. A software test driver automatic generation device according to claim 1, wherein the program is generated to execute the program for all test data.