MATERIALES DE REFERENCIA

First of all, a pointcut called asp is defined to capture for example the call of the method

send help(String Patient ID, String helpKind, String HelpCenter Name)5belonging to the class

HelpCenterAmbulatoryImpl (see lines 2-4). Then, the around advice captures the execution call and takes the decision to allow the execution of the corresponding method in case of business request (i.e., the operation will be normally executed by calling the keyword proceed (see line 33)). Otherwise, it prohibits the execution and sets up the appropriate test isolation technique before performing a test request. To do so, the testability options of each component under test are obtained from the RATP file (see lines 8-10). Given a test aware component under test, the input parameters are tagged with a special flag (see lines 18-20), for instance with “#”. In this case, this component is able to discriminate test data (i.e., tagged with “#”) from business data. Thus, the method is called with the new tagged parameters by using the keyword proceed (see line 21).

6.5

Selective Test Generation GUI

The RTF4ADS framework includes a selective test generation GUI to build automatically a new test suite after the occurrence of behavioral adaptations.

Figure 6.11: Screenshot of the selective test generation GUI.

The new test suite is composed of reusable and retestable tests, selected from the old test 5

This scenario belongs to an e-Health application in which an alarm component sends a help request to a help center, e.g., Ambulatory component, in case of emergencies.

6.5 Selective Test Generation GUI 92

suite, new tests generated from the evolved behavioral model by UPPAAL CO√ER (version

1.4) [109] and some adapted ones obtained by test recomputation. Once the new test suite is evolved, it is mapped to the TTCN-3 notation.

The first panel illustrated in Figure 6.11 deals with the model differencing step. Indeed, the

initial behavioral model and the evolved one are loaded, and then an Mdiff model highlighting

their similarities and their differences is computed. The next step consists in loading the old test suite and performing a test classification.

1 // Load the old trace

2 E x t r a c t X M L T r a c e s X M L T R = new E x t r a c t X M L T r a c e s ();

3 Vector < Trace > t r a c e s = X M L T R . e x t r a c t (" O l d T r a c e X M L . xml "); 4 // Read the SUT and ENV timed automata

5 T A _ a u t o m a t a S U T d i f f = a l g o . r e a d M o d e l (" SUT "); 6 T A _ a u t o m a t a E N V d i f f = a l g o . r e a d M o d e l (" ENV "); 7 A r r a y L i s t < state > S U T s t a t e s = S U T d i f f . g e t S t a t e s (); 8 A r r a y L i s t < state > E N V s t a t e s = E N V d i f f . g e t S t a t e s (); 9 for ( int i =0; i < t r a c e s . s i z e (); i ++) 10 { 11 T r a c e TR = n u l l ; 12 s t a t e S U T _ l 0 = a l g o . l o o k u p S t a t e ( S U T d i f f . g e t I n i t () , S U T s t a t e s ); 13 s t a t e E N V _ l 0 = a l g o . l o o k u p S t a t e ( E N V d i f f . g e t I n i t () , E N V s t a t e s ); 14 for ( int j =0; j < t r a c e s . get ( i ). s y n c . s i z e (); j ++)

15 {

16 if ( a l g o . I s t r a n s i t i o n R e a c h e d ( t r a c e s . get ( i ). s y n c . get ( j ) , SUT_l0 , E N V _ l 0 ))

17 {

18 S y m b o l i c S t a t e s y m b = a l g o . N e x t R e a c h e d S t a t e ( . . . ) ; // Look for the next reached state

19 S U T _ l 0 = s y m b . g e t S i (); 20 E N V _ l 0 = s y m b . g e t E i (); 21 } e l s e {

22 i n v a l i d e = t r u e ;

23 if ( a l g o . f i n d O l d T r a n s i t i o n ( . . . ) // the transition already exists in the old model

24 TR = new T r a c e ( t r a c e s . get ( i ). sync , " a b o r t e d "); b r e a k ;

25 e l s e

26 TR = new T r a c e ( t r a c e s . get ( i ). sync , " o b s o l e t e "); b r e a k ;}

27 }

28 if (! i n v a l i d ){

29 if ( a l g o . V e r i f C o l o r ( t r a c e s . get ( i ). sync , S U T d i f f . g e t T r a n s i t i o n s ( ) ) ) 30 // All the covered items are colored in Green

31 TR = new T r a c e ( t r a c e s . get ( i ). sync , " r e u s a b l e ");

32 e l s e

33 TR = new T r a c e ( t r a c e s . get ( i ). sync , " r e t e s t a b l e "); 34 } O l d T e s t S u i t e . add ( TR );

35 }

Listing 6.5: Test classification code snippet.

6.5 Selective Test Generation GUI 93

suite is made up of several traces in the XML format (see lines 1-3). Each trace is animated on the SUT and ENV models. Since a given synchronization action (i.e., traces.get (i ).sync.get (j )) in the old trace cannot be traversed, the test animation is abandoned (see line 21). At line 23, we check the existence of the corresponding transition in the evolved model. In such a case, the trace is classified as an aborted trace (see line 24). Otherwise, it is considered obsolete (see line 26). In lines 28-32, we classify valid traces into reusable or retestable traces.

Finally, we compute the new test suite by launching the UPPAAL CO√ER tool to generate

new tests, in a cost effective manner, by adapting obsolete and aborted tests and by including resuable and restestable tests.

Test generation tool UPPAAL CoVer

SUT and ENV automata .xml Observer automata Configuration file .cfg Test sequences .xml Query file .q automata .obs

Figure 6.12: UPPAAL CO√ER setup.

As shown in Figure 6.12, the UPPAAL CO√ER tool takes mainly as inputs :

• the Mdiff model (.xml), which is composed of a system part (SUT) and an environment

part (ENV),

• the observer (.obs), which expresses the adopted coverage criteria,

• a query file (.q) that is used to specify from which timed automaton or timed automata of the Mdiff the test suite is generated, and

• a configuration file (.cfg) that is used to format the generated traces to contain desired

information in the XML format.

The last panel is dedicated to perform the mapping of abstract test traces to the TTCN- notation. Once TTCN-3 test cases are compiled to be executable, test distribution, test isolation and test execution are performed as in the case of structural adaptations.

6.6 Summary 94

6.6

Summary

The achievement of a well-implemented prototype for runtime testing of dynamic adaptations was pinpointed in the present chapter. The obtained framework includes the realization of both approaches proposed to check structural and behavioral adaptations. Implementation details in terms of input files, output results and used tools required for each module were presented.

In the next chapters, we employ RTF4ADS to check the correctness of two critical case studies after the occurrence of either dynamic structural or behavioral adaptations. On the one hand, we illustrate the efficient execution of runtime tests in case of dynamically adapting the structure of an e-Health case study (see Chapter 7). On the other hand, RTF4ADS is used to evolve test suites when behavioral adaptations take place in the case of telematic application (see Chapter 8).

CHAPTER

7

Application of RTF4ADS After Structural Adaptations

7.1

Introduction

This chapter is mainly dedicated to show the relevance of our framework in case of structural adaptation occurrence. To do so, a remote medical care system is introduced and its implemen- tation details are highlighted in Section 7.2. In Section 7.3, several test scenarios are specified for the adopted case study. Their mapping to the TTCN-3 notation is also presented. Section 7.4 shows the applicability of RTF4ADS to check the case study correctness after structural adaptations. At the end, several experiments have been conducted in Section 7.5 to assess the overhead introduced by RTF4ADS as well as to show its efficiency to reveal adaption faults. The last section summarizes this chapter. Parts of this chapter have been published in [32, 96, 33].