The present invention relates to a test technique of exception handling in a program created by using an object-oriented programming language such as Java (trademark of Sun Microsystems, Inc.) or C++.
In program development, the number of steps required in a test process is very large. In the case where the quality is regarded as important, the ratio of the number of steps for a programming process and a test process becomes “programming”: “test”=2:8.
For the purpose of achieving the improvement in efficiency of a test as a significant problem in the program development as stated above, a test support tool is generally used. Current test support tools include a static test for analyzing programming contents and a dynamic test performed by executing an actually compiled program. By performing the respective tests, it is possible to perform tests supposed in software. However, with respect to exception handling which can be occur in a test depending on a hardware problem, such as a memory shortage at the time of program execution or a hard failure, and/or in the case where a problem relating to an OS (Operating System) or other software arises, it is very difficult to produce the exception state. Thus, in the development using the object-oriented programming language, a test for a location where an exception is handled has had to be performed after such an environment that the exception occurs is manually created in hardware, or after a dedicated test environment is separately prepared. That is, in the present circumstances, even if programming is performed with the programming language in which the logic of exception handling can be actually incorporated, it is difficult to completely perform the test.
For example, JP-A-5-257740 discloses a technique as described below. That is, in a case where a test is performed for each individual object of plural objects, the technique includes a translation processing of translating a source program to generate an object and external interface information, a linkage compile processing of generating an object on the basis of the external interface information with respect to an unsolved external call and unsolved external reference in the object and generating a program in an executable form, an execution processing of performing the execution control of the program in the executable form, an output data information storage of storing output information of the program in the executable form, an automatic execution processing of automatically performing execution on the basis of input data information storage storing input information for the program in the executable form, and a means of automatically judging an executed result by investigating the stored output information and output information outputted by the automatic execution processing. This publication does not particularly describe an exception.
As stated above, there is no related art enabling a test of exception handling to be automatically performed without preparing a special environment.
An object of the invention is therefore to provide a novel technique for automatically performing a test of exception handling in a program created by using an object-oriented programming language.
An exception test support method according to a first aspect of the invention comprises: if a source program to be tested is analyzed, and a specific method having a possibility that an exception occurs is detected in a specific class of the source program to be tested, storing data of the specific class, the specific method and the exception into a storage device; and referring to the storage device, generating an exception occurrence stub class as a class having the same name as the name of the specific class, wherein the exception occurrence stub has a method, which generates the exception and has the same name as the name of the specific method, and storing it into the storage device. As stated above, because the exception can be made to artificially occur by automatically generating the exception occurrence stub class, the test of the exception handling can be automated.
An exception test support method according to a second aspect of the invention comprises: analyzing a source program to be tested, specifying classes contained in the source program to be tested and methods contained in the classes, storing data of the classes and the methods into an analysis result storage, and if a specific method having a possibility that an exception occurs is detected in a specific class of the source program to be tested, storing line data of invoking the specific method into the analysis result storage; referring to the analysis result storage, generating a driver class (also called as a driver program) for invoking the method of the specified class, and storing it into a driver storage; causing the driver class stored in the driver storage to be executed, storing data of lines in the source program to be tested, which are executed by the driver class, so as to correspond to the driver class into an executed line data storage; and extracting the driver class for causing a line for invoking the specific method to be executed, based on the data stored in the analysis result storage and the data stored in the executed line data storage, and storing data of the extracted driver class into a storage device.
As stated above, by executing the driver class once and collecting data of the executed lines, it can be confirmed that the specific method having the possibility that the exception occurs can be invoked by executing which driver class, and it becomes possible to specify the driver classes necessary for the exception test without omission to the utmost.
In addition, the aforementioned analyzing may comprise: if the specific method having the possibility that the exception occurs is detected in the specific class of the source program to be tested, storing the exception data into the analysis result storage so as to correspond to the specific class and the specific method. At that time, the exception test support method according to the second aspect of the invention may further comprise: referring to the data stored in the analysis result storage, generating an exception occurrence stub class as a class having a same name as a name of the specific class, wherein the exception occurrence stub has a method, which generates the exception and has a same name as a name of the specific method, and storing it into an exception occurrence stub storage; and executing the driver class stored in the driver storage and the exception occurrence stub class stored in the exception occurrence stub storage in accordance with the data of the extracted driver class stored in the storage device, and storing execution result data into an execution result storage. As a result, the exception occurrence stub class for generating the exception is invoked by the specified driver class, and the test when the exception occurred can be executed.
The data of the extracted driver class may include correspondence data between the driver class and the specific method of the specific class. At that time, the executing and storing may comprise: when a specific driver class is executed, referring to the. correspondence data, and dynamically replacing (hot-swapping) the specific method of the specific class corresponding to the specific driver class with a method of the exception occurrence stub class having the same name as the name of the specific class. As a result, the exception occurrence stub class can be executed only when needed.
The exception test support method of the invention can be implemented by a computer and a program executed by the computer, and this program is stored in a storage medium or a storage device such as, for example, a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, or a hard disk. The program may be delivered as digital signals through a network or the like. Incidentally, intermediate processing results are temporarily stored in a storage device such as a main memory.
The source file storage 1 stores a file such as a source program to be tested. The source analyzer 3 performs an analysis processing of the source program to be tested stored in the source file storage 1, and stores an analysis result into the source analysis result DB 5. The driver generator 7 uses the data stored in the source analysis result DB 5 to automatically generate driver classes for invoking all methods in the source program to be tested, and stores data of the generated driver classes into the driver storage 12. The driver execution processor 13 executes the driver classes stored in the driver storage 12 to execute relevant lines of the source program to be tested stored in the source file storage 1, and stores data concerning the execution lines into the coverage data storage 15. The driver extractor 17 refers to the data stored in the source analysis result DB 5 and the data stored in the coverage data storage 15, extracts, in driver classes stored in the driver storage 12, a driver class for invoking a method having a possibility that an exception occurs in the source program to be tested, and stores data of the extracted driver class into the extracted driver data storage 19. The exception occurrence stub generator 9 refers to the data of the source analysis data storage 5, automatically generates an exception occurrence stub class corresponding to the method having the possibility that the exception occurs in the source program to be tested, and stores it, together with associated data, into the exception occurrence stub storage 11. The test execution manager 21 refers to the data stored in the extracted driver data storage 19, executes the driver class extracted by the driver extractor 17 in the driver classes stored in the driver storage 12, executes the method of the exception occurrence stub class stored in the exception occurrence stub storage 11 instead of the method having the possibility that the exception occurs, and stores an execution result into the execution result data storage 23. The output processor 25 presents the data stored in the execution result data storage 23 to the user. In each of the processing elements, there is also a case where reference is made to a storage not shown in
Next, the processing flow of the exception test support apparatus shown in
It is assumed that for example, MemGet( ) method of MemTest class as shown in
With respect to the ExClass1 class (shown in
Further, with respect to the ExClass 2 class (shown in
Next, the driver generator 7 generates driver programs in order to execute all methods by referring to the source analysis result DB 5, and stores them into the driver storage 12 (step S3). As described above, with respect to the source program to be tested, for each class, names of methods contained in the class are registered in the source analysis result DB 5, and accordingly, the driver program is generated by using the data. In general, various branches are contained in the source program to be tested, and in order to perform the exception test without omission, it is necessary to generate drivers passing through all the branches. Accordingly, in this embodiment, with respect to each of the methods, the driver program for executing the method is generated. Basically, because the driver program has only to invoke a specific method, it includes functions of (1) preparation of the execution (connection processing or the like (in the case of Enterprise Java Beans (EJB), servlet or the like)), (2) invocation of the constructor (invoke the constructor of the class to be tested), (3) invocation of a specific method in the source program to be tested (including: preparing method parameters, preparing method return values, invoking the method and recording method return values), and (4) end processing (disconnection processing or the like). For example, in the case of the driver program for invoking the MemGet( ) method of the MemTest class shown in
Next, the driver execution processor 13 causes all the driver programs stored in the driver storage 12 to be executed, acquires executed line information (called as coverage data) in the source program to be tested, through which the execution flow passes when executing each driver program, and stores it in the coverage data storage 15 (step S5). The coverage data is managed for each driver.
For example, in the case of the MemGet( ) method of the MemTest class shown in
The exception occurrence stub generator 9 refers to the source analysis result DB 5, generates an exception occurrence stub class performing only a processing to throw an exception expected to occur, and stores it in the exception occurrence stub storage 11 (step S7). More specifically, in the source analysis result DB 5, data of the exception to occur (name of exception for which throws declaration is made), the class for which the data is registered and the method in which the exception occurs are specified, a table to generate the exception occurrence stub is prepared, and the source program of the exception occurrence stub class is generated in accordance with the table. Also with respect to the table to generate the exception occurrence stub, in the case of FIGS. 3 to 5, for the memtest( ) methods of the ExClass1 class and ExClass2 class, data of “E1_Exception” and “E2_Exception”, and “E3_Exception” and “E4_Exception” of the exceptions that occur are registered. Accordingly, for example, a table as shown in
Next, the driver extractor 17 uses the coverage data stored in the coverage data storage 15 and the source analysis result stored in the source analysis result DB 5, extracts a driver program invoking a method having a possibility that an exception occurs, and registers data, such as the correspondence between the method having the possibility that the exception occurs and the driver, into the extracted driver data storage 19 (step S9). By referring to the source analysis result, the line number of the line invoking the method having the possibility that the exception occurs can be specified. On the other hand, the coverage data includes data as to which line was executed for each driver program. Accordingly, the line number of the line invoking the method having the possibility that the exception occurs is specified from the source analysis result, the coverage data including the line number is specified, and the driver program corresponding to the coverage data is extracted. Then, the driver program name and the method having the possibility that the exception occurs are stored in the extracted driver data storage 19.
For example, in the case where the source analysis result includes the data indicating that a line invoking a method having a possibility that an exception occurs exists at lines “32” and “33” of
Incidentally, there is also a case where the line number of a line invoking a method having a possibility that an exception occurs is registered in coverage data of plural driver programs. In such a case, the driver program detected first is extracted. However, a driver program in which a route to the method to be invoked is shortest is optimum, and if possible, such a driver program is extracted. Incidentally, the case where a route is short includes a case where the number of execution lines is small, and a case where an execution time is short. The latter case can be changed according to various conditions such as machine environment at that time and data. However, according to circumstances, in the case where one driver program is selected from plural driver programs, there is also a case where the driver program is selected in which the number of execution lines is small.
Then, the test execution manager 21 refers to the extracted driver data storage 19, the exception occurrence stub storage 11, and the driver storage 12, causes the driver extracted at the step 9 to be executed, causes a suitable exception occurrence stub class to be dynamically replaced (hot-swapped) and to be executed, and stores execution result data into the execution result data storage 23 (step S11). More specifically, the data (
In the case of
As the execution result, the executed class and method, the exception to be processed (in the case of Java, exception to be caught) the method of the invocation source of the exception, the exception thrown by the method, the output result and the like are stored in the execution result data storage 23.
In response to a request from the user, the output processor 25 uses the data stored in the execution result data storage 23 to form a display screen, and displays it on a display device (step S13). For example, a screen as shown in
The user judges from the display contents whether there is no problem, and in the case of approval (there is no problem), a check is placed in the column 116 of the approval. That is, with respect to the input of the check, the output processor 25 receives it, and registers it in, for example, the execution result data storage 23 so that reference can be made thereto later.
By such display, it is possible to perform confirmation as to whether the test has been performed without omission, as to whether there is no problem in programming, and as to whether there is the exception which is caught by only Exception( ). Further, it becomes also possible to find a portion requiring correction when there is something wrong.
As described above, according to this embodiment, the logic of exception handling implemented in the software developed by the user can be tested in the automatically generated environment, and the number of steps required to generated the environment of the software test until now can be greatly reduced. Besides, with respect to a location of the exception handling in which it is difficult to actually generate the software test environment, and a check operation has not been strictly performed even in the test process, it becomes possible to perform the strict test. As a result, a higher reliable program test can be performed, and the quality improvement of the software can be realized.
Although the embodiment of the invention has been described, the invention is not limited to this. For example, the functional block diagram of
The exception test support apparatus is a computer, and the computer has a configuration as shown in
Although the present invention has been described with respect to a specific preferred embodiment thereof, various change and modifications may be suggested to one skilled in the art, and it is intended that the present invention encompass such changes and modifications as fall within the scope of the appended claims.
Number | Date | Country | Kind |
---|---|---|---|
2004-154234 | May 2004 | JP | national |