Paul Clements
Paola Inverardi
Ivano Malavolta
ABSTRACT
Currently, software testing is mainly carried on independently from software architecture-related information. Some approaches propose to perform integration and regression testing with respect to software architecture descriptions, but less attention has been paid to analysing software architecture in order to develop a less costly and time-consuming test plan that covers the requirements of the system of interest. If on one side, it is well known that providing an effective test plan is crucial to software quality, on the other side software testing is extremely difficult because it stems from the complexity of current software systems.
In this paper we (i) elaborate on how a new architectural analysis can help in producing better test plans and (ii) identify a set of corresponding research challenges. We believe that considering and analysing architectural information for requirements satisfaction testing purposes will provide substantial benefits in terms of test plan specification process, test plan effectiveness, and test cases understandability.
- A. Bertolino and P. Inverardi. Architecture-based software testing. In Joint proceedings of the second international software architecture workshop (ISAW-2) and international workshop on multiple perspectives in software development (Viewpoints '96) on SIGSOFT '96 workshops, ISAW, pages 62--64. ACM, 1996. Google Scholar
Digital Library
- P. Clements, J. Hudak, P. Place, A. Bertolino, H. Muccini, and P. Inverardi. Architecture Support for Testing: Connecting Research to Practice. Technical Report, SEI report, in progress, 2011.Google Scholar
- G. T. Daich, G. Price, B. Ragland, and M. Dawood. Software Test Technologies Report. Technical Report p. 11, Software Technology Support Center, August 1994.Google ScholarCross Ref
- D. Di Ruscio, I. Malavolta, H. Muccini, P. Pelliccione, and A. Pierantonio. Developing next generation ADLs through MDE techniques. In Int. Conf. on Software Engineering, ICSE 2010, 2010. Google ScholarDigital Library
- A. C. Dias-Neto and G. H. Travassos. A picture from the model-based testing area: Concepts, techniques, and challenges. volume 80 of Advances in Computers, pages 45--120. Elsevier, 2010.Google Scholar
- A. Douglas. Linking requirements and implementation. Views on Evolvability of Embedded Systems, pages 137--151, 2011.Google Scholar
- R. Dssouli and R. Fournier. Communication Software Testability. In IFIP Transactions, Protocol Testing Systems III (the Proceedings of IFIP TC6 Third International Workshop on Protocol Test Systems), pages 45--55, 1991.Google Scholar
- R. Dunn. Software defect removal. McGraw-Hill, Inc., New York, NY, USA, 1984. Google ScholarDigital Library
- M. Escalona, J. Gutierrez, M. Mejías, G. Aragón, I. Ramos, J. Torres, and F. Domínguez. An overview on test generation from functional requirements. Journal of Systems and Software, 84--6:1379--1393, 2011. Google ScholarDigital Library
- R. Freedman. Testability of software components. IEEE Transactions on Software Engineering, 17:553--564, 1991. Google ScholarDigital Library
- A. Goknil, I. Kurtev, K. van den Berg, and J. Veldhuis. Semantics of trace relations in requirements models for consistency checking and inferencing. Software and Systems Modeling, pages 1--24, 2009. Google ScholarDigital Library
- B. Hailpern and P. Santhanam. Software debugging, testing, and verification. IBM Syst. J., 41:4--12, January 2002. Google ScholarDigital Library
- J. Hall, M. Jackson, R. Laney, B. Nuseibeh, and L. Rapanotti. Relating software requirements and architectures using problem frames. In Proceedings of the IEEE Joint Int. Conf. on Requirements Engineering, 2002., pages 137--144. IEEE, 2002. Google ScholarDigital Library
- IBM. IBM Rational Unified Process (RUP).Google Scholar
- V. Jeffrey M. Factors that affect software testability. Technical report, NASA, 1991. Google ScholarDigital Library
- Q. Li, M. Li, Y. Yang, Q. Wang, T. Tan, B. Boehm, and C. Hu. Bridge the gap between software test process and business value: A case study. In Proceedings of the International Conference on Software Process: Trustworthy Software Development Processes, ICSP, 2009. Google ScholarDigital Library
- S. Pandey and K. Mustafa. Recent advances in sre research. Recent Advances in SRE Research, 2(04):1079--1085, 2010.Google Scholar
- D. J. Richardson and A. L. Wolf. Software testing at the architectural level. In Joint proc. of the second int. software architecture workshop (ISAW-2) and int. workshop on multiple perspectives in software development (Viewpoints '96) on SIGSOFT '96 workshops, ISAW '96, pages 68--71. Google ScholarDigital Library
- E. Woods and N. Rozanski. Unifying software architecture with its implementation. In Proceedings of the Fourth European Conference on Software Architecture, pages 55--58, New York, NY, USA, 2010. ACM. Google ScholarDigital Library
Index Terms
- Exploiting software architecture to support requirements satisfaction testing
Recommendations
Using Software Architecture for Code Testing
Abstract--Our research deals with the use of Software Architecture (SA) as a reference model for testing the conformance of an implemented system with respect to its architectural specification. We exploit the specification of SA dynamics to identify ...
A defect prevention approach to architecture-based testing
COMPSAC '97: Proceedings of the 21st International Computer Software and Applications ConferenceResearch in software architectures often marginalizes the importance of testing in relation to architectural design decisions. It is the authors' belief that testing has a pivotal role in software architectural design, in particular, defect prevention ...
Towards Destructive Software Testing
ICIS-COMSAR '06: Proceedings of the 5th IEEE/ACIS International Conference on Computer and Information Science and 1st IEEE/ACIS International Workshop on Component-Based Software Engineering,Software Architecture and ReuseTraditional software testing checks to see if a software product meets specifications. This generally involves testing to see if the software performs all the functions called for in the Software Requirements Specifications (SRS). In contrast, this work-...
Comments