1. Field of the Invention
The present invention relates to an object state classification method and system that are used to define pseudo-states in order to enhance the efficiency of tests in an object-oriented program.
2. Description of the Related Art
In predominant techniques of a unit test for a class in an object-oriented program, a variety of methods are called in association with an object that takes various states.
These techniques are disclosed in, for instance, Jpn. Pat. Appln. KOKAI Publication No. 9-325952; Jpn. Pat. Appln. KOKAI Publication No. 7-262044; Hyoung Seok Hong, Young Rae Kwon, and Sung Deok Cha, “Testing Object-Oriented Based on Finite State Machine”, Asia-Pacific Software Engineering Conference, December 1995, p. 234; and D. C. Kung, N. Suchak, J. Gao, and P. Hsia, “On Object State Testing”, COMPSAC: Computer Software and Applications Conference 1994, IEEE Computer Society Press, 1994, p. 222.
In these techniques, a program designer determines which states are present in a class. However, in most cases, it is not clearly defined which states are present in individual classes.
In a possible method for efficiently testing a class, a concrete state is created from abstract states (e.g. where states are defined by ranges of member variables), and this concrete state is used for the test. However, this method is feasible only after the state is defined. Conversely, if the state of the class is not clearly defined, the efficiency of the test cannot be achieved based on “state of class”.
As stated above, unless the state of each class is defined, a general technique to be used for the test is as follows. As many as possible concrete states (obtained by setting values in individual member variables; hereafter referred to as “concrete state”) are created as testers for tests of classes, and the concrete states are used to perform tests. It is likely that a plurality of concrete states, which are considered to belong to the same semantic group, are present in these many created concrete states. It is thus possible to consider that the “state” intended by the designer is a set of semantically equal concrete states.
However, the efficiency of testing deteriorates if a test is conducted for each of the semantically equal concrete states. This is explained in brief referring to FIG. 19A to FIG. 19C. FIG. 19A is a view illustrating an example of a list containing one class, the presence/absence of the definition of the designer's intended state associated with the class, and test cases associated with the presence/absence of the definition. In the case where the designer's intended state is defined, as shown in FIG. 19C, methods are called on the basis of only “concrete state 1” corresponding to the “designer's intended state”, and the number of test cases is only two. On the other hand, in the case where the designer's intended state is not defined, as shown in FIG. 19B, methods are called based on all assumed concrete cases, that is, “concrete state 1” and “concrete state 2”, and the number of test cases is four, which is double the number in the case where the designer's intended state is defined.
The reason for this problem is that the state of the class, unless defined by the program designer, cannot be determined from the outside.