Expressing and implementing operational profiles ... - Semantic Scholar

Expressing and implementing operational profiles for reactive software validation L. du Bousquet

F. Ouabdesselam

J.-L. Richier

LSR-IMAG, BP 72, 38402 Saint Martin d’H`eres, France E-mail: fldubousq, ouabdess, [email protected] Abstract

Lutess integrates several test data generation techniques. The first one produces input data, so that the occurrence probability of each input state is the same. Such an assumption does not fit most of the reactive software environments, since all input states do not have the same occurrence probability. Therefore, we introduced a new input generation method, which allows the tester to specify each input variable probability [10]. The main drawback of this approach is that users have difficulties to relate the input variable probabilities they provide to the operational profile they would like to be applied. To overcome this problem, our proposal is to define a way of describing operational profiles. This paper is concerned with how to derive the input variable probabilities from the operational profile and how the test data generation process is performed according to the operational profile. The whole method relies on the implementation structure of the environment, that is binary decision diagrams. In the literature, most works on operational profiles assume that actual software usage can be described by assigning unconditional probabilities to software inputs [5, 6, 8]. Whittaker [14] has designed an operational profile specification method in which the probability that an input state is issued is conditional upon which input state was issued immediately prior to it. Woit [15] has described another method in which the probability of issuing a module input depends on any previous input. Our work shares some analogies with the two cited works. Like Whittaker’s, our approach uses Markov chains to model the usage of the specified software. This model is an automaton. However, in our case, the automaton states synthesize the past history of the software usage, and not only the input state which was issued immediately prior to it. This leads to a more precise description of the software environment, which was the main goal of Woit’s work. In this paper, we use the classical terminology of software reliability. An operational profile is a quantitative characterization of how a system will be used [7]. It is taken into account for the test, in such a way that the most-used

Lutess is a tool that we developed for testing reactive synchronous software and which is being used in different industrial contexts. It offers several formal testing methods with automatic generation of test data from the environment specification. Lutess provides also an approach to assign a probability to the next event issued by the environment. However, a Lutess’ user faces the problem of expressing operational profiles with sophisticated and varying probability assignments to software inputs, in a format directly usable by Lutess. The paper concentrates on how to express operational profiles for specifications which are implemented as Binary Decision Diagrams.

1. Introduction Since Musa’s pioneering work on operational profiles, several approaches based on operational profiles have been proposed to assess software reliability [15, 14]. This assessment requires a specification of the software environment, including a characterization of the relationships between the environment entities, as well as the definition of the environment entity domains. Concerning reliability, reactive programs are an interesting class of software to be dealt with, for two reasons. Usually, this type of software is involved in safety-critical systems. Thus, assessing its partial correctness or its reliability with testing is necessary whenever a proof of correctness is impossible. Second, the safety-critical system environment is described in details: the environment has properties that the system must maintain, and several environment behaviors can be ruled out. We have developed a formal framework and its associated tool, Lutess, to test a reactive synchronous software. This tool produces automatically and dynamically test data with respect to an environment formal specification [9, 11]. 1

operations will receive the most testing. An operational profile associates a set of probabilities to the program input space. A program input space is the set of all possible input states. An input state is an assignment of values to all of the program input vector, that is the list of all program input variables. The following section illustrates the use of Lutess on a simple example, and explains the test data generation algorithms. Section 3 shows how an unconditional probability distribution should be provided to Lutess, and how it is taken into account in the generation process. Section 4 enriches the method with conditional probability distributions.

is labeled with the value taken by that variable. An example of BDD is given in Fig. 3.

2.2

An example

Let’s consider the following example of a 3-button mouse conversion program. This program is an interface between a 3-button device and an application program (see Fig. 1). It transforms “physical clicks” on a mouse into “logical clicks” usable by the application program.

mouse

B : button number conversion program

2. Lutess

ty : click_type

physical click

Lutess is a tool which provides a framework for testing synchronous reactive programs. Reactive programs interact continuously with their environment [13]. Synchronous programs [2] is an sub-class of reactive software: every reaction of a program to its inputs is theoretically instantaneous. Synchronous programs have cyclic behaviors: at each tick of a global clock, all inputs are read in and all the outputs are emitted. Lutess is concerned with programs whose inputs and outputs are boolean. Lutess requires a formal specification of the environment (as a set of constraints).

2.1

Lutess principles

Lutess includes a random simulator of the environment, which produces input data which are valid with respect to this environment description. In order to produce those correct data, Lutess builds a generator specific to the given environment description. The generator construction consists in compiling the environment constraints into a finite state automaton. This automaton recognizes all program input and output value sequences satisfying the constraints [12]. The automaton is implemented using a symbolic notation in which the states are represented by a set of variables, and the transitions by boolean functions. A state corresponds to one or more different values of the state variables. A boolean function is associated with each state variable to compute the next value of this variable from the current values of the state, input and output variables. So, the computation of the next state is based on the use of all these boolean functions. Another boolean function is associated with the automaton, to check whether the environment constraints are satisfied for a given state and a given value of the inputs and outputs. The boolean functions are implemented as Binary Decision Diagrams (BDD) [1, 3], which are known as an efficient data structure for the boolean calculus. Each node of a BDD carries a variable and each of its outgoing branches

application program

R : button number logical click

Figure 1. The mouse conversion program. A physical click corresponds to the action of clicking one button. It is not possible to press two buttons simultaneously. A logical click is simple, double or triple. Let T be an integer constant defining the time lap during which a triple click can occur; T is greater or equal to 3 ticks (T  3). A triple click results from three clicks on the same button in a row in less than T ticks. A double (reps simple) click is obtained when the same button is pressed twice (resp. once) in a row in less than T ticks. A triple click has a priority over simple and double clicks. A double click has a priority over a simple click. The inputs of the conversion program are the button numbers (B) : Bj is true when one clicks on the j -th button (j 2 f1; 2; 3g). (B1,B2,B3) is the input vector. The outputs of the conversion program are couples of values. The first component is the click type (ty1 : simple, ty2 : double or ty3 : triple). The second one is the button number (Rj : logical click on the j -th button). We call “click-construction phase” the period of time between the occurrence of a physical click and the emission of the associated logical click signal. Figure 2 gives an illustration of the conversion program expected behavior. B ty R B ty R

1

1

2 1 1

1

1 1 2

1 3 1 1

1

1 1 1 1 3 1

1 2 1

... ... ...

Figure 2. An example of the mouse conversion program expected behavior with T=4.

For sake of presentation, in the figures, the BDDs are always represented by Shannon trees (ST). Figure 3 shows

B1 [0]

[1]

B2

B2

[0]

[1]

B3 [0] 1

[0]

B3

B3

[1] [0]

[1] [0]

1

0

1

[1]

1

B3 [1]

[0]

[1]

0

0

0

Figure 3. ST defining the mouse environment constraint. state variables output variables local variables input variables

(BDD upper part)

(input sub-BDD)

Figure 4. A schematized BDD. the ST associated with the BDD built by Lutess for the mouse environment constraint. This constraint is stated in English as: “at most one button among B1, B2 and B3 can be clicked at the same time”. In the ST, 0 and 1 stand for respectively false and true. Each node, except for the leaves, carries an input variable (a button). The left (resp. right) sub-ST corresponds to the assignment of a false (resp. true) value to the root variable. A path from the ST root to a leaf represents an input state. If the input state is valid with respect to the environment constraints, the terminating leaf carries a true value. The input space contains 8 input states, among which only 4 are valid.

states and the outputs of the conversion program. On the contrary, the BDDs shown in Fig. 9 include state variables. Let us focus now on the basic generation algorithm. To test reactive programs, an input state should be exhibited at each execution cycle (or instant). Let Choice be the function which computes the input state at each instant. This function implements a random testing process with equally probable occurrence of the input states. The Choice function is based on a specific environment BDD labeling. Let (e0 :::en) be the input vector, such that if i i 1 1 > if 2 then 2 else < if r then r else v v+v > with v1 and v0 refering to the basic labeling > : p e

ce

p

ce

p

0

1

1

( = false) = (1 ? ( i = true)) p e

With the two last algorithms, the resulting input state probability distribution may surprise the user. Indeed, he often does not evaluate the impact of the environment constraints on the random generation. A rigorous approach to random generation is proposed to the user. It is based on operational profiles and is developed in sections 3 and 4.

3. Unconditional probability distribution Actually, each BDD node could carry a probability information given by the user. In the following, this information is called a coefficient (ci). For the mouse example, these coefficients are shown in Fig. 6. The array at the bottom of the Shannon tree summarizes the input space: the grayed elements represent invalid input states. c0 c1 c3

c2 c4

c5

c6

111 000 11 00 00 11 00 11 000 111 00 11 00 11 11 00 000 11 111 00 00 11 00 11

Figure 6. Lutess conditional probability coefficients. User-defined conditional probabilities must be provided to Lutess in the form of a list:

8 C(B1) = > > = > < CC(B2) (B3) = > > > :

0 , when true 1 , when (: B1); c2, when B1 c3 , when (: B1 ^: B2); c4 , when (: B1 ^ B2) c5 , when (B1 ^: B2); c6 , when (B1 ^ B2), c c

0.2 0.4 0.3

11 00 00 000 111 00 11 000.1 11 11 00 11 000 111 00 11 00 11 11 00 000 111 00 11

Figure 7. An operational profile for the mouse example.

p

ce

p ei

Let us consider an example of an operational profile for the mouse environment specification (Fig. 7). This operational profile provides an unconditional probability value for each possible input state.

From this operational profile, the Lutess user must first determine the ci coefficient values. Then, using these values, he must provide the list of conditional probabilities associated with each software input variable.

3.1

Coefficient computation : a first algorithm

To define the value of the ci coefficients, an equational system must be written. This system relates the probability of each input state to the probability of the corresponding path in the environment BDD (expressed in terms of ci ). The Shannon tree in Fig. 6 leads to the following equational system:

8 > > > > > < > > > > > :

(1 ? 0 ) (1 ? 1 ) (1 ? 3 ) (1 ? 0 ) (1 ? 1 ) 3 (1 ? 0 ) 1 (1 ? 4 ) (1 ? 0 ) 1 4 0 (1 ? 2 ) (1 ? 5 ) 0 (1 ? 2 ) 5 0 2 (1 ? 6) c

:

c

:

c

:

c

:c

c

:c :

c

:c :c

c

c :

c

:

c :

c

:c

c :c :

c

c

c

0 2 6

c :c :c

= P(: B0 ^: B1 ^: B3) = P(: B0 ^: B1 ^ B3) = P(: B0 ^ B1 ^: B3) = P(: B0 ^ B1 ^ B3) = P(B0 ^: B1 ^: B3) = P(B0 ^: B1 ^ B3) = P(B0 ^ B1 ^: B3) = P(B0 ^ B1 ^ B3)

The solution of this equational system for the operational profile example in Fig. 7 is :

8 > > > > > < > > > > > :

8 (1 ? 0) (1 ? 1 ) (1 ? 3 ) = 0.2 > (1 ? 0) (1 ? 1 ) 3= 0.4 > > (1 ? 0) 1 (1 ? 4) = 0.3 > < (1 ? 0) 1 4 = 0 ) > 0 (1 ? 2) (1 ? 5) = 0.1 > > 0 (1 ? 2) 5 =0 > : 0 2 (1 ? 6) = 0 c

:

c

:

c

:

c

:c

c

:c :

c

:c :c

c :

c

:

c :

c

:c

c :c :

c

0 2 6= 0

c :c :c

c

c

c

0 = 0.1 1 = 1/3 c2 = 0 c3 = 2/3 c4 = 0 c5 = 0 c6 = c

c

It should be noted that the equational system does not provide an unique and significant value for c6 . Indeed, in Fig. 6, c6 is associated with a sub-BDD root, for which the input space has not any valid input state. As a rule, any equational system can not set a significant value on such coefficients.

3.2

Coefficient computation : an efficient algorithm

In this paragraph, we propose a more efficient algorithm which relies on a new labeling of the environment BDD. The labeling of a node i consists of a couple (f0; f1 ), where f0 (resp. f1 ) represents the sum of the probabilities of the distinct input states include the node i with ei = 0 (resp. ei = 1). The resulting labeling for the mouse example is given in Fig. 8. The value of the coefficient ci is computed with the following formula : ci = f0f+1f1 . One can notice that the root label of the BDD describing the input space (e0 label) is such that its associated coefficient c0 = f0f+1f1 = f1 (since f0 + f1 = 1 by definition of a consistent operational profile). (9/10,1/10) (6/10,3/10) (2/10,4/10)

8 > > > > < > > > > :

(1/10,0)

(3/10,0)

(1/10,0)

(0,0)

11 00 00 11 00 11 00 11 00 11 00 00 11 00 11 1/10 11 00 11 11 00 00 11 00 11 = ( ) ( + ) = (0.1)/(0.9+0.1) = 0.1 0 1 0 1 2/10 4/10 3/10

c

f

= f

f

1 = (0.3)/(0.6+0.3) = 1/3 c2 = 0/(0.1+0) = 0 c3 = (0.4)/(0.2+0.4) = 2/3 c4 = 0/0.3 = 0 c5 = 0/0.1 = 0 c6 = 0/0 = not defined c

Figure 8. A example of probability distribution method labels.

3.3

Experimentation

Let us consider the mouse example and the given operational profile (Fig. 7). In the case of a 10000 step run, the expected input distribution is :

8 > < > :

B1 B2 B3 None

Estimation 1000 3000 4000 2000

test 1 1026 3016 3878 2080

test 2 1005 3073 3857 2065

Table 1. First experimentation summary. This list is inputed to Lutess. Table 1 shows the result of an elementary experimentation for two different runs. One can notice that the estimation and the results are really close.

4. Conditional probability distribution In [14], Whittaker notices how useful it is to maintain multiple probability distribution for each operation mode of the software. The aim of this section is to show that it is possible to express conditional probability distribution with Lutess. Unlike the example presented in Fig. 7, we want to express that the probability of clicking the button Bi depends on whether the conversion program is in a clickconstruction phase (see x2.2). For instance, outside the click-construction phase, the probability to press button Bi is 0.2, and, during the click-construction phase, the probability to press the same button is 0.6, whereas the probability to press another one is 0.2. Let M be a variable memorizing the last clicked button during the click-construction phase. M equals 0 when the program is not in a click-construction phase. Table 2 gives an operational profile for this situation.

P(B1=true) P(B2=true) P(B3=true) P(None)

(M=1) 0.6 0.1 0.1 0.2

(M=2) 0.1 0.6 0.1 0.2

(M=3) 0.1 0.1 0.6 0.2

(M=0) 0.2 0.2 0.2 0.4

Table 2. An operational profile example. P(B1) * Number of Steps = 1/10 * 10000 = 1000 P(B2) * Number of Steps = 3/10 * 10000 = 3000 P(B3) * Number of Steps = 4/10 * 10000 = 4000 P(None) * Number of Steps = 2/10 * 10000 = 2000

Applying our coefficient computation method, we obtain the following list of conditional probabilities:

8 C(B1) = 0.1, when (true) < = 1/3, when (: B1) : CC(B2) (B3) = 2/3, when (: B1 ^: B2)

4.1. The algorithm The translation of the operational profiles into Lutess expressions is carried out in two steps. The first stage is to apply the efficient algorithm (given x3.2), to determine the set of the coefficients ci . The result is presented in Fig. 9, where the triangles symbolize the sub-BDD concerned with the boolean constraints on the state and output variables.

M=3

(0.8,0.2)

(0.9,0.1)

(0.6,0.2)

(0.2,0)

(0.4,0.2) (0.2,0)

0.4 0.2 0.2

(0.2,0)

(0,0)

11 11 00 00 00 11 00 11 00 11 00 00 11 00 11 000.2 11 11 00 11 00 11 00 11

(0.8,0.1) (0.2,0.6)

(0.1,0) (0.1,0)

(0.1,0)

0.2 0.6 0.1

M=2

M=1 (0.4,0.6)

(0.2,0.1) (0.6,0)

(0.1,0) (0.1,0)

(0,0)

11 11 00 00 00 11 00 11 00 11 00 00 11 00 11 000.1 11 11 00 11 00 11 00 11

(0.3,0.1) (0.2,0.1) (0.1,0)

0.2 0.1 0.1

(0,0)

11 11 00 00 00 11 00 11 00 11 00 00 11 00 11 000.1 11 11 00 11 00 11 00 11

(0.9,0.1) (0.3,0.6)

0.2 0.1 0.6

on the program history. The history is composed of three pieces of information :

M=0

  

the time elapsed since the begining of the current clickconstruction phase as a number of ticks (t=1, t=2, or t=3). the number of physical clicks already issued during the click-construction phase (None, simple, or double).

(0.6,0) (0.6,0)

(0,0)

11 11 00 00 00 11 00 11 00 11 00 00 11 00 11 000.6 11 11 00 11 00 11 00 11

Figure 9. Conditional distribution.

The clicked button number has a symmetrical role, so it is of no need to differentiate the M values when M6=0. Fig. 10 provides the Markov chain corresponding to the operational profiles, based on the previous characterization of the history. A method to build such a Markov chain is given in [14].

In the triangles, only the conditions on M appear, since no other variable has an influence on the input state computation. The second phase is to construct the Lutess list of conditional probabilities. This is also done in two steps. From the input sub-BDD, for each coefficient, a condition is elaborated; it corresponds to the path which leads to the node carrying this coefficient. The expression is then extended with the condition on M. For the mouse example, this process results in the following list :

8 C(B1) : > > > > > > < C(B2) : > > > > > > : C(B3) :

a predicate stating whether a click-construction phase has begun or not (M6=0 or M=0),

0.4 None 1 0.6 !ty1

simple, t=1

2 0.2

0.2 !ty2 0.2

double, t=2 0.6

!ty1 0.2

0.6

!ty3

5

simple, t=2 0.2

!ty2 0.2

0.2, when (M=0) 0.6, when (M=1) 0.1, when ((M=2) _ (M=3)) 1/4, when (: B1 ^ (M=0)) 1/3, when (: B1 ^ (M=1)) 2/3, when (: B1 ^ (M=2)) 1/8, when (: B1 ^ (M=3)) 1/3, when (: B1 ^: B2 ^: (M=3)) 3/4, when (: B1 ^: B2 and (M=3))

4.2. Experimentation We study a three-button mouse conversion program, with a click-construction phase length (T ) equals to 4. The aim of this experiment is to check that Lutess generates random data with accordance to the expected input distribution. To make this observation easier, we assume that the conversion program is correct and we analyze the distribution of logical click types. This last distribution can be computed using the Markov chain theory. The probability to click a button depends

3

!ty1 0.2

!ty2 0.6

!ty3 0.2

0.2

0.6 double, t=3 0.6 !ty3

6

simple, t=3

4

0.2 !ty2

!tyi : conversion program output (ty1: simple, ty2: double, ty3: triple logical click)

Figure 10. Markov chain obtained for T=4 The Markov chain of the mouse example1 is represented by the following transition matrix T . This matrix gives the one step transition probabilities between the states.

0 BB B T =B BB @ 1 It

0.4 0 0 0.8 0.6 0.8

0.6 0.2 0.2 0.2 0.2 0.2

is irreducible and aperiodic.

0 0.2 0 0 0 0

0 0 0.2 0 0 0

0 0.6 0 0 0 0

0 0 0.6 0 0.2 0

1 C C C C C C A

SIMPLE DOUBLE TRIPLE None

Estimation 838 786 1650 6726

test 1 999 898 1798 6305

test 2 964 834 1823 6379

test 3 976 861 1780 6383

test 4 940 877 1794 6389

Table 3. Results of the second experiment.

The output distribution we are interested in can be deduced from the long run state distribution of the Markov chain. Markov theory allows us to compute this state distribution by taking powers of the matrix until convergence (T conv = limn!1 T n ). The rows of T conv are the same since the starting state has no impact on the long run statistics of an irreducible, aperiodic chain. Thus the long run state distribution of T is a row of T conv . For the mouse example and the Markov chain (Fig. 10), T conv is:

0 BB BB B@

.31877 .31877 .31877 .31877 .31877 .31877

T conv = limn!1 T n =

.32751 .32751 .32751 .32751 .32751 .32751

.065502 .065502 .065502 .065502 .065502 .065502

.013100 .013100 .013100 .013100 .013100 .013100

.19650 .19650 .19650 .19650 .19650 .19650

.078602 .078602 .078602 .078602 .078602 .078602

1 CC CC CA

Consequently, the probability of each logical click (P(tyi)) is :

8 > > < > > :

P(ty1) = 0.2*P(state=2) + 0.2*P(state=3) + 2*0.2* P(state=4)= 0.083842 P(ty2) = 0.6*P(state=4) + 0.2*P(state=5) + 2*0.2* P(state=6) = 0.078602 P(ty3) = 0.6*P(state=5) + 0.6*P(state=6) = 0.165065

Table 3 shows the result of a simple experimentation based on four 10000 step runs. Here again, one can notice that the estimation and the results are fairly close.

4.3

Generalization

From the experimentations, it seems that the method which has just been illustrated with the mouse example can be generalized to more complex operational profiles. At least, as long as the past history which is taken into account in the operational profile can be summarized in the upper part of the environment BDD. As we did for the mouse example, it is always possible to introduce state variables to synthesize conditional expressions.

5. Case study We have applied this approach to telecommunication system prototype [4]. The aim of this section is to illustrate the approach with this example. A telecommunication system prototype deals with several users. All of them can use the basic call service. This service allows them to initiate, maintain and close a communication. The basic call service defines three basic actions: a user can off the hook, on the hook, or dial. Each user can subscribe to additional services. A new service offers new abilities. The Short Dial service (SD subs) allows the subscriber to dial a shortened number (short dial) instead of the usual full number asked by the basic call service (dial). The Call Forward service (CF subs) allows the user to forward his call to a chosen number. The subscriber can activate the service (CFon) or deactivate the service (CFoff) whenever he wants. Let P a telephony system dealing with those three services. P input vector is (On, Off, Dial, Short Dial, CFon, CFoff). The environment constraints are : a user can not off (resp. on) hook twice without on (resp. off) the hook in between; and a user can dial (resp. short dial, activate, deactivate call forward service) only if its telephone is in the Dialing state; all the input are mutually exclusive. The probability distribution of the possible actions in the dialing state depends on the user service subscription. (Someone who is not a call forward service subscriber may not try to activate this service). For this reason, we have defined several operational profiles in function of the subscription list. Table 4 gives an example of two operational profiles. OP1 defines the action distribution in dialing state when the user has no subscription. OP2 defines the action distribution in dialing state when the user is both short dial service and call forward service subscriber. Once operational profiles defines, we applied the algorithm given in section 4. Table 5 describes the conditional probabilities we obtained. We applied Markov theory to estimate the occurrence number of each action for 2000 steps in Dialing state, in function of the operational profiles (see Table 6). Then, we used Lutess with the conditional probabilities. We produced a test run a test long enough to include 2000 steps in Dialing state for each configuration (see Table 7). One can notice how close are the expected and final results. OP 1 2

dial 70% 50%

short dial 1% 20%

CFon 1% 20%

CFoff 1% 5%

Off 1% 1%

none 26% 4%

Table 4. Different operational profiles.

Input dial short dial CFon CFoff Off dial short dial CFon CFoff Off

Probability 0.707 .034 0.035 0.01 0.505 0.408 0.689 0.555 0.01

Condition

: (SD subs _ CF subs) ^ Dialing state (SD subs ^ CF subs) ^ Dialing state

Table 5. Conditional probabilities associated with previous operational profiles. OP 1 2

dial 20 20

short dial 1400 1000

CFon 20 400

CFoff 20 400

Off 20 100

none 520 80

Table 6. Expected results for 2000 step in Dialing state.

6. Conclusion This paper has described an approach to express operational profiles for synchronous reactive software and implement them. The approach is general enough to allow realistic descriptions of the operating environment. The operational profile specification technique gives a way of assigning to the next input state a probability depending on the program history. We have shown how the associated testing tool (Lutess) should be used to take into account a specification including a conditional probability distribution. Some experiments have been conducted to demonstrate the feasibility of this approach. We have applied this approach to telecommunication system prototypes. It has revealed itself very useful to generate realistic input data and has helped us focus the testing effort on the most frequent usages.

References [1] S. Akers. Binary Decision Diagrams. IEEE Transactions on Computers, C-27:509–516, june 1978. [2] A. Benveniste and G. Berry. The Synchronous Approach to Reactive and Real-Time Systems. Proceedings of the IEEE, 79(9):1270–1282, september 1991. [3] R. Bryant. Graph-based algorithms for boolean functions manipulation. IEEE Transactions on Computers, pages 667–692, august 1986.

OP 1 2

dial 1472 1002

short dial 21 25

CFon 18 401

CFoff 31 405

Off 18 90

Nothing 530 73

Table 7. Final results for 2000 step in Dialing state.

[4] L. du Bousquet, F. Ouabdesselam, J.-L. Richier, and N. Zuanon. Incremental feature validation : a synchronous point of view. In Feature Interactions in Telecommunications Systems V. IOS Press, 1998. [5] J. Duran and S. Ntafos. An Evaluation of Random Testing. IEEE Transactions on Software Engineering, 10(4):438– 444, july 1984. [6] D. Hamlet and R. Taylor. Partition Analysis Does Not Inspire Confidence. IEEE Transactions on Software Engineering, pages 1402–1411, december 1990. [7] J. Musa. Operational Profiles in Software-Reliability Engineering. IEEE Software, pages 14–32, march 1993. [8] G. Myers. The Art Of Software Testing. Wiley-Interscience, 1979. [9] F. Ouabdesselam and I. Parissis. Testing Synchronous Critical Software. In 5th International Symposium on Software Reliability Engineering, Monterey, USA, november 1994. [10] F. Ouabdesselam and I. Parissis. Constructing operational profiles for synchronous critical software. In 6th International Symposium on Software Reliability Engineering, pages 286–293, Toulouse, France, october 1995. [11] I. Parissis. A Tool for Testing Synchronous Critical Software. In 3rd International Conference on Achieving Quality in Software, Florence, Italie, january 1996. [12] I. Parissis and F. Ouabdesselam. Specification-based Testing of Synchronous Software. In 4th ACM SIGSOFT Symposium on the Foundation of Software Engineering, San Francisco, USA, october 1996. [13] A. Pnueli. Application of temporal logic to the specification and verification of reactive systems : a survey of current trends. Current Trends in Concurrency, LNCS, SpringerVerlag, 224:510–584, 1986. [14] J. Whittaker. Markov chain techniques for software testing and reliability analysis. Thesis, University of Tenessee, May 1992. [15] D. Woit. Specifying Operational Profiles for Modules. In International Symposium on Software Testing and Analysis, pages 2–10, Cambridge, Massachusetts, USA, june 1993.