1. Testing Implementation Conformance with respect to its Architectural specification Software Architectures and Testing Begin Antonia Bertolino IEI - CNR, Pisa bertolino@iei.pi.cnr.it bertolino@iei.pi.cnr.it Paola Inverardi, Henry Muccini University of L’Aquila {inverard, muccini}@univaq.it

2. 2 Main Research Area Software Architectures and Testing HenryMuccini   Integration Testing + Integration Testing +   Software Architecture = Software Architecture = Architecture-based Testing Keywords:   Testing: Integration Testing, Functional Testing   SA: Architectural Languages, models and views   Traceability, Graph coverage, Click

3. 3 High level Description Software Architectures and Testing HenryMuccini Testing Implementation Software Specification (informal) Formal Architectural Description drives

4. 4 Overview on SA and Testing Overview on SA and Testing Software Architectures and Testing HenryMuccini

5. 5 Software Architecture (SA)   Describes (in a formal language) how a system is structured into components and how these components interact    SA:   Structure (statics)   Behavior (dynamics)   Given the SA description (in some ADL), the model can be automatically generated; the dynamics is expressed in terms of components interactions via connectors Architectural Description Language Software Architectures and Testing HenryMuccini

6. 6 TestingTesting   Testing is a process of executing a program with the intent of finding errors or defects: a successful test is one that uncovers an as yet undiscovered error.   To increase our confidence in the proper functioning of the software.   Not exaustive approach Module UnitIntegration System Module M M M M Structural Functional Software Architectures and Testing Code Level Oriented to Syntax Unit Tests Functional properties Formal specifications

7. 7 Architecture-based Integration Testing   Integration Testing: interconnects sets of previously tested modules to ensure that the sets behave as well as they did as independently tested modules. Integration Testing is aimed at exposing problems in the interfaces and interactions between the system components   Functional: focus on the functional requirements of the software   Architectural: information for testing are extracted from the Architectural specification Software Architectures and Testing HenryMuccini

8. 8 Motivations and ExpectedBenefits Motivations and ExpectedBenefits Software Architectures and Testing HenryMuccini

9. 9   To combine Structural and Specification-based Testing   To mitigate their respective problems   To handle complexity in the testing of large systems   To detect and eliminate problems as early as possible   Test planning interwoven with development and evolution (from Requirements to Code)   High reusability   CBSE and COTS Software Architectures and Testing HenryMuccini

10. 10 The SA-based Testing Approach Software Architectures and Testing HenryMuccini

11. 11 Software Architectures and Testing [ICECCS’97] Abstract LTS Architectural Test Plan Testing the Implementation Software Architecture formal description Global LTS [ICSE00] [ICSE01] The Approach [IR22/00]

12. 12 Assumption Assumption:   Architectural Description Language (ADL) that produces a global Labelled Transition System (LTS) in which:   L defines the LTS labels, also called LTS actions   Nodes carry on info about the state of each SA component   Arcs carry on info about the interactions ADL Formal Description Software Architectures and Testing HenryMuccini [ICSE00] [ICSE01]   Chemical Abstract Machine (CHAM)   Finite State Process (FSP)   Dynamics in terms of Component interactions Used ADLs

13. 13   Each LTS complete path represents a possible behavior, i.e. an LTS complete path could be taken as a test class   BUT…a lot of information (views) in a single graph and we can select many many potential test classes… how to select interesting test classes? Software Architectures and Testing HenryMuccini

14. 14   Architectural Views   Flow view   Component Based view   Concurrency view  ...   Given the LTS, we apply an Obs Functions to view the system only from a perspective that is relevant for testing   Obs : L  D  {  }   Minimization and Reduction The Abstraction Operational Description (LTS) Observation View (ALTS) Dynamic View Software Architectures and Testing HenryMuccini

15. 15 Flow view: ComponentBased View: Software Architectures and Testing HenryMuccini

16. 16   ALTS Path Coverage   Each complete path corresponds to an Architectural Test Class... Architectural Test Class Software Architectures and Testing HenryMuccini

17. 17 G G SendAlarm1.ReceiveAck1 corresponds to many LTS complete paths [IR22/00] ReceiveAck1 SendAlarm1 A B From ALTS to LTS Software Architectures and Testing HenryMuccini

18. 18 Testing the Software Implementation   Given ar architectural path to be tested:   We can verify this behavior against the Requirements.   We can test whether the system as-built implements this architectural behavior   How are the LTS paths implemented by the Code? Re-Architecting Context   SA and Code have been developed independently :   Design is independent of the SA topology   SA after Implementation Forward Development   SA drives the system design:   COTS   Component Based Software Architectures and Testing HenryMuccini

19. 19 Re-Architecting Context Software Architectures and Testing HenryMuccini   Let act1, act2, …, actN the LTS actions, each Test class is composed by a sequence of these actions and: 4.1 Each path may be represented by an architectural scenario; 4.2 For each action, we try to understand how these functionalities are implemented by the source code 4.3 The source code scenarios are put together to implement the test class, i.e., tha architectural scenario 4.4 The tester runs the code

20. 20 Software Architectures and Testing HenryMuccini

21. 21 ResultsResults Software Architectures and Testing HenryMuccini

22. 22 Software Architectures and Testing HenryMuccini

23. 23 Results and Future Works   We found an architectural error in the TRMCS case study, BUT...   … we need to compare our approach with other functional testing approaches.   To apply this approach to an italian telecommunication system   To encrease the integration testing approach automation   To use model-checking to manage the state explosion problem and to verify the architectural behavior againts the requirements Software Architectures and Testing HenryMuccini

24. Henry Muccini muccini@univaq.it http://www.dm.univaq.it/~muccini Henry Muccini Ph-D Student in Computer Science University of L’Aquila - Italy muccini@univaq.it http://www.dm.univaq.it/~muccini

25. [ICECCS’97] A. Bertolino, P. Inverardi, H. Muccini and A. Rosetti. An Approach to Integration Testing Based on Architectural Descriptions On IEEE Proc. ICECCS-97, Como, 1997. [ICSE2000] A. Bertolino, F. Corradini, P. Inverardi, H. Muccini. Deriving Test Plans from Architectural Descriptions. Proc. 22nd Int. Conf. on Softw. Eng. (ICSE2000), June 4th-11th, 2000. [IR22/00] A. Bertolino, P. Inverardi and H. Muccini Specification-based Testing In-The-Large Driven by the Software Architecture IR 22/00, University of L'Aquila.On-line at:http://www.dm.univaq.it/~muccini/Page2.html [ICSE2001] A. Bertolino, P. Inverardi and H. Muccini. An Explorative Journey from Architectural Tests Definition downto Code Tests Execution Proc. 23nd Int. Conf. on Softw. Eng. (ICSE2001), May 2001. ReferencesReferences