Data processing: measuring – calibrating – or testing – Testing system – Of circuit
Reexamination Certificate
2001-10-11
2004-11-23
Hoff, Marc S. (Department: 2857)
Data processing: measuring, calibrating, or testing
Testing system
Of circuit
C702S109000, C702S118000, C702S120000
Reexamination Certificate
active
06823281
ABSTRACT:
BACKGROUND OF THE INVENTION
Componentized software is software that is designed to allow different pieces of the application, or “objects”, to be created separately but still to have the objects work together. For this to happen, the objects must have standard interfaces that can be understood and accessed by other objects. The software language enforces some parts of these interfaces. If software interfaces are not directly available as part of the system, a discovery mechanism is employed to find the interface information. If the interfaces are not used, the software objects will not be able to work with other objects. Other practices are imposed by convention. Because these programming practices are known to everyone, the companies that create the containers can rely on them when creating the container. As a result, if these practices are not followed, the container might not operate properly. Thus, there is an indirect mechanism for enforcing these practices.
Test code can be generated by using the attributes of the platform independent language in which the software is written. Enterprise Java Beans (EJB) by Sun Microsystems, COM, DCOM, COM+ and SOAP (Simple Object access Protocol) by Microsoft Corporation and CORBA by IBM are examples of component specification standards that are commercially available. For the example of Sun JAVA language being used here, each bean has an application program interface described in a specification published by SUN Microsystems, called EJB Specification versions 1.0, 1.1, and 2.0. More particularly, each bean has a “home” interface and a “remote” interface. The “home” interface reveals information about the methods for creating or finding a remote interface in the bean. The remote interface reveals how this code can be accessed from client software. Of particular interest in the preferred embodiment, the home and remote interfaces provide the information needed to create a test program to access the bean.
Using the reflection, a program can determine what are known as the “properties” and “methods” of a bean. The properties of a bean describe the data types and attributes for a variable used in the bean. Every variable used in the bean must have a property associated with it. In this way, the software can automatically determine what methods need to be exercised to test a bean and the variables that need to be generated in order to provide stimulus to the methods.
The methods of a bean describe the functions that bean can perform. Part of the description of the method is the properties of the variables that are inputs or outputs to the method. A second part of the description of each method—which can also be determined through the reflection interface—is the command needed to invoke this method. The detailed description of the method's name, parameters and return value is specified in Remote or Home interfaces and can be also determined with Reflection API available in Java language itself. Because software can determine the code needed to invoke any method and can generate data values suitable to provide as inputs to that method, the software can generate code to call any method in the bean.
Currently, test code can be generated for testing a software component from meta-data descriptions of technology specific component interfaces. However there is not enough semantic content with respect to the code order or argument composition to generate the methods so the test execution is guaranteed to produce meaningful results (also known by the term “Realistic Test”). It is entirely possible the methods may not be in the correct order, thus the generated test code may not be testing a scenario that would likely happen during actual use of the software component. For example, for a banking application, the methods may be generated such that an account is accessed before the account has been created. The customer would have to review the order of the methods in order to insure that the method ordering was correct. The same problem arises when automated software attempts to generate parameters to the method from primitive type objects. In order to create a parameter the object software has to instantiate the object and then call some of the methods. It is not very obvious how to instantiate the object (which constructor or factory to call) and then which methods and in which order to execute on the object in order to bring the object into the state to be used as a parameter for the method.
SUMMARY OF THE INVENTION
With the foregoing background in mind, it is an object of the present invention to provide correctly ordered test code in order to effectively test software components and applications. There are software diagramming tools on the market today that capture software designs in a standard meta-language (UML). This software provides sequence diagrams that relate to the software component being analyzed. The UML sequence diagrams expose enough semantic content to allow the generation of test code correctly ordered. Since all of the objects are modeled consistently, the data requirements of the software component can also be determined. As a result, the generated test code is correctly ordered, thereby providing a more accurate, useful and real-world testing environment of the software component and applications incorporating the components.
REFERENCES:
patent: 5870539 (1999-02-01), Schaffer
patent: 5930798 (1999-07-01), Lawler et al.
patent: 5983001 (1999-11-01), Boughner et al.
patent: 6192511 (2001-02-01), Johnston et al.
patent: 6226692 (2001-05-01), Miloushev et al.
patent: 6266447 (2001-07-01), Hoshi et al.
patent: 6275956 (2001-08-01), On et al.
patent: 6292933 (2001-09-01), Bahrs et al.
patent: 6493425 (2002-12-01), Abe
patent: 6505342 (2003-01-01), Hartmann et al.
patent: 6609128 (2003-08-01), Underwood
Friedman George
Glik Michael
Makar-Limanov Sergei
Chapin & Huang , L.L.C.
Empirix Inc.
Rouille, Esq. David W.
Suarez Felix
LandOfFree
Generation of correctly ordered test code for testing... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Generation of correctly ordered test code for testing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Generation of correctly ordered test code for testing... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3339609