Patent
1995-06-16
1998-08-11
Voeltz, Emanuel Todd
G06F 945
Patent
active
057940436
DESCRIPTION:
BRIEF SUMMARY
BACKGROUND OF THE INVENTION
The contribution that the software supplies to the solution also increases with the increasing scope of system solutions within the framework of large-scale industrial projects. In order for one to be able to efficiently execute large software products, it has proven advantageous to subdivide these projects into sub-projects and to modularly produce individual programs. A not insignificant aspect in the modular production of programs is also that individual program modules can be easily re-exploited by other projects. In recent years, the technique of object-oriented programming has proven advantageous in this context.
In conjunction with the re-employability of individual program modules, it is especially the quality assurance of these program modules that acquires increased significance. The demands of an especially error-free quality of individual program structures are met by specially developed testing procedures. A significant concern of software testing is to document the quality of the software within the framework of the test coverage. The greatest variety of testing methods are conceivable for assisting the tester in his work. One attempts to make a continuous test of the software of individual program modules up through the complete system possible with these testing methods. In particular, one distinguishes between three tests building on one another: the component test, the integration test, and the system test. The component test has the goal of finding errors in the individual program component. The components, traditionally, are a matter of one or more modules, for example of classes in object-oriented programming. The component test is supplemented by the integration test, with whose assistance errors at the interfaces and in the communication between the tested components are discovered. Finally, a system test can be implemented, this representing a test from the viewpoint of the customer (for example the test of a complete switching-oriented system). The goal thereof is to test the stability of the entire (program) system under "load", i.e. real through extreme conditions.
Within the framework of the technique of object-oriented programming, the component test is presented by a testing method for classes. Meaningfully, one begins the test in individual program components, i.e. the classes. When one builds on untested classes in the test of a program, the errors that were made in the class implementation are not detected or are only detected with far greater difficulty and, correspondingly, are more difficult to eliminate. The reason for this in addition to the poor surveyability of the overall program lies in the mixing of these functional errors with those that occur in the interaction of the individual objects (communication or, respectively, interface errors). Another significant reason for well-tested classes is the enhanced readiness resulting therefrom of being able to reemploy these classes. Qualitatively poor software is obviously not suitable for reemployment.
As a rule, classes as test subjects are not capable of being run by themselves and can thus not be debugged with a debugger of an operating system without additional outlay. Since these classes of test subjects only represent program structures, it is absolutely necessary to derive objects from them for their test. They are then tested in that corresponding methods at the objects are called in and executed. The parameters of a method call together with the values of the data components of an object to be called then represent the test data.
The technique of object-oriented programming is comparatively young. There is therefore no technical method for testing classes of object-oriented software. If a programmer wished to test a class in a traditional way, then he would first have to generate a test case, i.e. write a program that instances an object from a class. Further, he would have to work method calls, including parameter values for this object, into this program in the front-end of the tes
REFERENCES:
patent: 5339433 (1994-08-01), Frid-Nielsen
patent: 5418964 (1995-05-01), Conner
patent: 5421016 (1995-05-01), Conner
patent: 5432903 (1995-07-01), Frid-Nielsem
patent: 5493680 (1996-02-01), Danforth
patent: 5557730 (1996-09-01), Frid-Nielsen
patent: 5652835 (1997-07-01), Miller
Fielder, S.P., "Object-oriented unit testing," Hewlett-Packard Journal, v40, n2, p. 69(6), Apr. 1989.
Rettig, M., "Testing made palatable," Comms. of the ACM, v34, n5, p. 25(5), May 1991.
Automatisierungstechnische Praxis--ATP, vol. 31, No. 1, Jan. 1989, G. Pauthner et al., "TBM, ein vollstandig generierbares Software-Modultestbett", pp. 30-36.
Proceedings of the Conference on Software Maintenance, 27 Oct. 1988, Tomaz Dogsta et al., "CAMOTE--Computer Aided Module Testing and Design", pp. 404-408.
Proceedings of the 9th Digital Avionics Systems Conference, 18 Oct. 1990, Gary L. Dehlin, "Automating Test Driver Generation", pp. 107-110.
Corcoran, III Peter J.
Siemens Aktiengesellschaft
Todd Voeltz Emanuel
LandOfFree
Method for testing at least one class of an object-oriented prog does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for testing at least one class of an object-oriented prog, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for testing at least one class of an object-oriented prog will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-401605