ACM Home Page
Please provide us with feedback. Feedback
Testing levels for object-oriented software
Full text PdfPdf (163 KB)
Source International Conference on Software Engineering archive
Proceedings of the 22nd international conference on Software engineering table of contents
Limerick, Ireland
Pages: 136 - 145  
Year of Publication: 2000
ISBN:1-58113-206-9
Authors
Y. Labiche  LAAS-CNRS/LIS 7, Avenue du Colonel Roche, 31077 Toulouse Cedex 4, France
P. Thévenod-Fosse  LAAS-CNRS/LIS 7, Avenue du Colonel Roche, 31077 Toulouse Cedex 4, France
H. Waeselynck  LAAS-CNRS/LIS 7, Avenue du Colonel Roche, 31077 Toulouse Cedex 4, France
M.-H. Durand  Aerospatiale Matra Airbus/LIS, Département Systèmes (BTE/SY/MS), 316 route de Bayonne, 31060 Toulouse Cedex 3, France
Sponsors
IEEE-CS : Computer Society
SIGSOFT: ACM Special Interest Group on Software Engineering
Irish Comp Soc : Irish Computer Society
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 43,   Downloads (12 Months): 239,   Citation Count: 5
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues  

Tools and Actions: Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/337180.337197
What is a DOI?

ABSTRACT

One of the characteristics of object-oriented software is the complex dependency that may exist between classes due to inheritance, association and aggregation relationships. Hence, where to start testing and how to define an integration strategy are issues that require further investigation. This paper presents an approach to define a test order by exploiting a model produced during design stages (e.g., using OMT, UML), namely the class diagram. Our goal is to minimize the number of stubs to be constructed in order to decrease the cost of testing. This is done by testing a class after the classes it depends on. The novelty of the test order lies in the fact that it takes account of: (i) dynamic (polymorphism) dependencies; (ii) abstract classes that cannot be instantiated, making some testing levels infeasible. The test order is represented by a graph showing which testing levels must be done in sequence and which ones may be done independently. It also provides information about the classes involved in each level and how they are involved (e.g., instantiation or not). The approach is implemented in a tool called TOONS (Testing level generator for Object-OrieNted Software). It is applied to an industrial case study from the avionics domain.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
 
2
R. V. Binder, "Testing Object-Oriented Software: a Survey," Software Testing, Verification & Reliability, vol. 6 (3/4), pp. 125-252, 1996.
3
4
 
5
6
 
7
D. Kung, J. Gao, P. Hsia, J. Lin and Y. Toyoshima, "Class Firewall, test order, and regression testing of object-oriented programs," Journal of Object-Oriented Programming, vol. 8 (2), pp. 51-65, 1995.
8
 
9
 
10
J. Mc Gregor, "Let's Don't and Say We Did," Journal of Object-Oriented Programming, vol. 11 (5), pp. 6- 11,14, 1998.
 
11
 
12
K.-C. Tai and F. J. Daniels, "Interclass Test Order for Object-Oriented Software," Journal of Object-Oriented Programming, vol. 12 (4), pp. 18-25,35, 1999.
 
13
 
14
 
15


Collaborative Colleagues:
Y. Labiche: colleagues
P. Thévenod-Fosse: colleagues
H. Waeselynck: colleagues
M.-H. Durand: colleagues